Release Notes
Quota and Flow Control Mechanism Description
What Is the Flow Control Mechanism
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 gracefully 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 with low tolerance for QoS 0 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, the processing policy is more rigorous and differentiates based on the protocol version of the publishing 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 read 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.
Workflow
1. The server reads a Publish packet from the MQTT session.
2. The server attempts to acquire the processing quota for the session or tenant cluster. If the quota is exhausted, the server pauses reading data from the TCP Recv-Q and sets a scheduled task to acquire quota in the next allocation window.
3. Once sufficient quota is acquired to process the packets already read into the MQTT session, the server resumes the TCP Recv-Q reading process.
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, the client may disconnect due to a Keep-Alive timeout.
2. During flow control, the system strives to ensure that higher-QoS messages are prioritized for quota allocation within the processing window while discarding QoS 0 Publish packets. However, absolute prioritization is not guaranteed.
3. During flow control, waiting to acquire quotas introduces additional latency for Publish packet processing.
MQTT v5.0 Clients
Flow Control Principles
The server sends a PUBACK/PUBREC packet to the client with the protocol-defined Reason Code 0x97, explicitly indicating Quota Exceeded. Application developers must handle the corresponding exceptions and error codes, for example, by implementing retries based on application requirements.
Reason Code | Name | Packet | Description |
0x97 (151) | Quota Exceeded | PUBACK, PUBREC | Indicates 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:
For the downlink traffic flow control mechanism — the quota mechanism governing message pushes from the MQTT server to subscribed clients — a limited "Burst" capability is provided to ensure timely delivery of published messages and a better user experience: the server allows the current batch of pushes to complete even when the quota is briefly and slightly exceeded.
Help and Support
Was this page helpful?
You can also Contact sales or Submit a Ticket for help.
Help us improve! Rate your documentation experience in 5 mins.
Feedback