Quota and Flow Control Mechanism Description
Last updated:2026-01-30 14:59:40
Flow Control Mechanism Refers To
Quotas and flow control serve as critical service assurance mechanisms for MQTT products. Their primary purpose is to restrict client requests when tenant cluster quotas or user-defined per-session quotas are exhausted, preventing service overload that could lead to resource exhaustion, sharp performance degradation, or even system crashes—all of which compromise service availability. In MQTT services, flow control typically governs client behaviors such as connections, message publishing, and message subscriptions. For instance, when the server detects that a client's publish traffic exceeds its per-session quota or the tenant cluster collectively surpasses the instance quota, flow control is triggered.
This document details how TDMQ for MQTT implements differentiated and fine-grained flow control policies based on message QoS levels and client protocol versions. Through flow control mechanisms, the system can maximize service availability under pressure scenarios while providing feedback mechanisms for clients of different versions.
Implementation Principles
To ensure business continuity for customers, TDMQ for MQTT implements fine-grained flow control on producer-side traffic based on QoS levels and client protocol versions. The core strategy is: to prioritize high-level messages, rapidly restrict low-level messages, and efficiently notify clients through differentiated feedback mechanisms, achieving a balance between availability and reliability.
QoS 0 Messages
Flow Control Principles
When a client's QoS 0 message publish rate exceeds the quota, the server directly discards the excess QoS 0 messages.
Note:
QoS 0 is inherently an "at-most-once" delivery mechanism that provides no reliability guarantees. Messages may be discarded due to network issues or other factors. At the protocol level, clients should not expect reliable delivery for QoS 0 messages. For business scenarios requiring low tolerance for message loss, the business side should implement monitoring and retry policies to mitigate such risks.
QoS 1 Messages and QoS 2 Messages
For QoS 1 (AT-LEAST-ONCE) and QoS 2 (EXACTLY-ONCE) messages, our processing policy is more cautious and differentiates based on the protocol version of the sending client to enhance service quality.
MQTT v3.1 and v3.1.1 Clients
Flow Control Principles
Flow control is implemented using the backpressure mechanism of the TCP protocol. When a single MQTT session or tenant cluster exceeds its quota, the MQTT Server will suspend reading inbound data from that TCP connection. Data in the TCP Recv-Q will only be processed again after quota becomes available. During flow control, client Publish packets will be buffered either in the client application-layer Buffer or the TCP Send-Q.
Operation Process
1. The server reads a Publish packet from the MQTT session.
2. Attempt to obtain processing quotas for the session or tenant cluster; if the quota is exhausted, pause reading data from the TCP Recv-Q and set a scheduled task to obtain quotas in the next allocation window;
3. After sufficient quotas are obtained to process the packets in the MQTT session, the TCP Recv-Q reading process is resumed.
Warning:
1. During TCP backpressure flow control, Keep-Alive packets sent by the client cannot be read promptly. If a tenant instance significantly exceeds its quota, this may cause the client to disconnect due to keep-alive timeout.
2. During flow control, the system strives to ensure that higher QoS levels are prioritized for quota processing within the processing window, while discarding QoS 0 Publish packets, but absolute priority cannot be guaranteed.
3. During flow control, the process of waiting to obtain quota quotas will introduce additional delays in handling Publish packet requests.
MQTT v5.0 Client
Flow Control Principles
The server sends a PUBACK/PUBREC packet to the client, explicitly notifying "Quota Exceeded" using the protocol-defined Reason Code 0x97. Application developers must handle corresponding exceptions and errno, such as retrying later based on business requirements.
Reason Code | Name | Packet | Description |
0x97 (151) | Quota Exceeded (quota limit exceeded) | PUBACK, PUBREC | Used to indicate that the quota has been exceeded. The server restricts the publisher's sending quota based on cluster specifications. When a publisher exceeds the quota, the server uses this reason code in acknowledgment packets (such as PUBACK and PUBREC) to notify the publisher. |
Note:
Regarding the downlink traffic flow control mechanism, which is a quota mechanism for the MQTT server to actively push messages to subscribed clients, we provide a limited "Burst" service to ensure timely processing of published messages and a good customer experience: the server allows completing the current batch of pushes when instantaneously slightly exceeding the quota.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback