Receive Maximum
Last updated:2026-01-30 14:59:40
Overview
In IoT applications, device capabilities vary. Some resource-constrained devices may be unable to handle large volumes of incoming messages simultaneously. To address this, MQTT 5.0 introduces a flow control mechanism based on sending quotas, whose core implementation is the Receive Maximum attribute. Receive Maximum aims to prevent the message sending rate from exceeding the receiver's processing capacity, thereby avoiding receiver overload crashes and enhancing communication reliability and stability.
This Is Receive Maximum
Receive Maximum is a parameter negotiated during connection establishment, present in both the client's CONNECT packet and the server's CONNACK packet. It represents the maximum number of unacknowledged QoS 1 or QoS 2 PUBLISH packets that a communicating party (client or server) is willing to handle concurrently, that is, the maximum available sending quota.
Simply put, when client A connects to the server:
Client A can set a Receive Maximum, such as 10, in the CONNECT packet. This is equivalent to instructing the server: "You can send me a maximum of 10 QoS>0 messages simultaneously. Do not send the 11th until I have acknowledged them."
Similarly, the server can also return a Receive Maximum, such as 50, in the CONNACK packet. This is equivalent to telling client A: "You can have a maximum of 50 QoS>0 messages 'in flight' to me."
How It Works
The implementation of Receive Maximum relies on a dynamic "sending quota" counter:
1. Initial state: When a connection is established, the sender's initial available quota is set equal to the receiver's declared Receive Maximum value.
2. Sending message: Whenever the sender transmits a QoS 1 or QoS 2 PUBLISH packet, its available quota is decremented by 1.
3. Acknowledgment reception: When the receiver returns the corresponding acknowledgment packet (PUBACK for QoS 1, PUBREC or PUBCOMP for QoS 2), the sender's available quota is incremented by 1.
4. Quota exhaustion: If the available quota decreases to 0, the sender must cease sending any new QoS 1 or QoS 2 messages until acknowledgment packets are received and the quota is replenished.
5. Violation Handling: If the receiver detects that the peer violates this rule (for example, sending QoS>0 messages when the quota is 0), it must treat this as a protocol violation and disconnect to protect itself.
Note:
The Receive Maximum mechanism applies only to QoS 1 and QoS 2 messages. QoS 0 messages (at most once delivery) have no corresponding acknowledgment packet and are therefore not subject to this quota limitation.
The MQTT 5.0 specification provides a non-mandatory recommendation for this scenario:
When the sender's quota is 0, it may choose to continue sending QoS 0 messages or pause transmission.
Best practice is to pause sending. Since if the response to QoS 1/2 PUBLISH packets slows down, it typically indicates that the receiver's consumption capacity has already decreased. Continuing to send QoS 0 messages at this point would only exacerbate the issue.
Advantages and Value
Despite the limitations in controlling QoS 0 messages, the Receive Maximum mechanism still offers significant benefits:
Preventing overload: Provides reliable protection for core message transmission (QoS 1/2), ensuring that the receiver does not crash due to message flooding.
Dynamic and efficient: The acknowledgment-based quota recovery mechanism allows the sender to maximize the utilization of network bandwidth and the receiver's processing capacity, thereby maximizing resource utilization.
No pre-negotiation required: Both connecting parties declare their capabilities when establishing the connection, which eliminates the need for complex additional negotiation at the application layer and ensures transparent communication.
Heterogeneous system compatibility: This mechanism offers significant flexibility when devices from different vendors with varying processing capabilities are integrated.
Receive Maximum is a key feature introduced in MQTT 5.0 to enhance protocol reliability and resource management. Through an elegant sending quota model, it effectively addresses flow control for QoS 1 and QoS 2 messages. Although its control over QoS 0 messages is advisory rather than mandatory—presenting certain limitations—this mechanism remains a significant advancement in MQTT evolution. It is strongly recommended that users actively leverage this feature in MQTT 5.0-supported environments to build more robust and stable IoT applications.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback