In the MQTT 5 CONNECT packet, set the Receive Maximum property to the maximum number of QoS 1 and QoS 2 publishes the client can handle concurrently (e.g., 10 for a constrained device).
The broker honours this limit and does not send more than Receive Maximum unacknowledged QoS 1/2 PUBLISH packets to the client at any time.
The client tracks in-flight messages and only sends PUBACK or PUBCOMP to release a slot; do not send DISCONNECT without draining or the broker may resend on reconnect.
For device-to-cloud publishing, set the broker-side Receive Maximum in the CONNACK to cap the device's own outgoing QoS 1/2 in-flight window.
Combine Receive Maximum with the Session Expiry Interval property on CONNECT to control how long the broker retains undelivered QoS 1/2 messages across disconnections.
Monitor the Topic Alias Maximum property from the CONNACK to know how many topic aliases the broker supports before using aliases to reduce per-message overhead.
Known gotchas
Receive Maximum applies only to QoS 1 and QoS 2 messages; QoS 0 messages are fire-and-forget and are not subject to this flow control window.
If the client closes the connection without sending DISCONNECT and reconnects with the same client ID and Session Expiry Interval > 0, the broker resumes the session and the in-flight window resets, potentially re-delivering messages.
Not all MQTT 5 brokers implement Receive Maximum enforcement; test broker behaviour explicitly rather than assuming the limit is enforced.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp