How to Tune MQTT Inflight and Queue Limits for a Slow Link

Back to Blog

Understand Why the Window Fills on a Slow Link

At QoS 1 and 2, a published message is not done until its acknowledgement returns. The client holds each unacknowledged message in an inflight window and will not exceed that window's size. On a link where the round trip is long, acknowledgements come back slowly, so at a steady publish rate the window fills with messages still waiting to be confirmed. Once full, the client cannot send more until an acknowledgement frees a slot.

That is the crux: on a fast link the window never fills because acknowledgements return faster than you publish; on a slow link it fills routinely. The receiver side of this is governed by a negotiated maximum - see MQTT receive maximum and flow control - and the sender must respect it. The publish rate, the latency, and the window size together decide whether you stall.

Size the Inflight Window to the Link Latency

Set the inflight window large enough that the client can keep publishing while earlier messages are still awaiting acknowledgement. Conceptually, the window needs to hold about as many messages as you will publish during one round-trip time, so that by the time the window would fill, the first acknowledgements are already returning to free slots. A window sized for a LAN will throttle a satellite link badly.

Do not simply set the window enormous, though. A very large inflight window on a link that then drops means a large batch of unacknowledged messages all needing redelivery on reconnect, which can flood the recovered link. Size it to keep the pipe full at your real publish rate, with headroom, not to an arbitrary large number. The exact latency is link-specific and must be measured, not assumed.

Size the Send Queue for Bursts and Outages

Behind the inflight window sits the client's send queue - messages waiting to enter the window. This queue absorbs bursts and short outages. Size it to hold the telemetry generated during the longest interruption you want to ride through without loss, so that when the link returns, the queue drains rather than having overflowed. A queue too small drops the oldest or newest messages during any hiccup.

But a deep queue has a cost: during a real outage it fills with aging data, and when the link returns the client dumps a backlog of stale values. Decide whether stale backlog or dropped data is worse for your application, and size accordingly. For genuine outage survival you often want a store-and-forward layer rather than an unbounded client queue - see store and forward telemetry.

Match the Publish Rate to What the Link Sustains

Tuning the buffers only helps if the average publish rate fits within what the link can acknowledge over time. If you publish faster than the link can carry indefinitely, no window or queue size saves you - the backlog grows without bound until something drops. So confirm the sustained publish rate is below the link's sustained throughput, and use the buffers only to absorb the peaks around that average.

If the sustained rate is too high, cut it at the source: raise deadbands, lengthen publish intervals, or batch. The QoS choice interacts here too, because QoS 2's extra round trips cost the most window occupancy - reconsider whether every high-rate topic needs it, using choosing an MQTT QoS for telemetry.

Verify Under a Degraded Link

Test with the real link degraded, not at full signal. Publish at your expected steady rate and confirm the client does not stall or drop - watch that the inflight window cycles rather than pinning full. Then simulate a short outage and confirm the send queue absorbs it and drains cleanly on recovery, without a flood of stale data or a gap.

Confirm nothing was silently lost by checking a payload sequence number across the outage: no gaps means the buffers held. If you see gaps, either the queue was too small for the outage length or the sustained rate exceeds the link and the backlog overflowed. The buffers that survive your worst realistic outage without loss are the ones to deploy.

Common Mistakes

The core mistake is leaving the inflight window at a LAN-appropriate default on a satellite or cellular link, so it pins full and throttles publishing far below what the link could carry. The opposite mistake is a huge window that dumps a redelivery flood on every reconnect.

Another is treating buffer tuning as a substitute for a sustainable publish rate: if you publish faster than the link can ever carry, no buffer size helps. And do not confuse the client's send queue with real store-and-forward - an unbounded client queue full of stale data on recovery is not the same as a disciplined buffer that keeps only what matters.

Frequently Asked Questions