In the MQTT 5 Essentials, we explore the foundational changes that MQTT 5 introduces and the top reasons MQTT users make the move to MQTT v5. Our goal is to individually examine each of the new features in the MQTT 5 protocol. Today, we’ll continue with another useful feature: Flow Control.

At the end of this blog post, we have a video on the same topic that complements this blog post.

Modern IoT projects are often big and complex. These large-scale projects usually require the collaboration of multiple vendors and teams. Since MQTT is the de facto standard protocol for IoT, improved interoperability and transparency across systems topped the list of user requirements for MQTT version 5.

Today’s feature helps meet those user requirements.

Flow Control

IoT deployments and use cases usually consist of multiple device types. MQTT clients that are embedded in a small sensor can have significantly different characteristics than those that are part of a high-performance back-end server. For example, processing speed or storage capabilities. This means that the different MQTT clients have different tolerance levels for managing in-flight messages. In this context, an in-flight message is a PUBLISH with a Quality of Service of one or two that has not yet been acknowledged. Similarly, an IoT device can connect to multiple MQTT brokers that have different restrictions for the number of in-flight messages from an MQTT client that they can manage. To address the varying conditions among clients MQTT and brokers in a transparent manner, MQTT 5 introduces the Flow Control feature.

How it works

Client and broker negotiate each other’s in-flight windows during the connection establishment. The client can set an optional property called Receive Maximum in the CONNECT packet (Client Receive Maximum). This value tells the broker the maximum number of unacknowledged PUBLISH messages the client is able to receive. The broker responds with an optional value for Receive Maximum in the CONNACK packet (Server Receive Maximum). This value tells the client the maximum number of unacknowledged PUBLISH messages the broker is willing to receive. If this the Receive Maximum value is absent, the default value of 65,535 is used.

Advantages and details

The Flow Control feature enables dynamic message flow adjustment for use cases that involve multiple of non-identical systems and devices (for example, an IoT platform that services multiple tenants). It also creates transparency and flexibility in circumstances where multiple teams or vendors are involved in the same project. With this feature, it is no longer necessary for all involved parties to negotiate in-flight windows beforehand. If an MQTT 5 client sends more unacknowledged messages than the Server Receive Maximum allows, the broker sends DISCONNECT with Reason Code 0x93 (Receive Maximum exceeded). Both client and broker can choose to send less in-flight messages than the corresponding Receive Maximum allows.

Conclusion

• The use of Receive Maximum is optional
• Client and broker can define their own in-flight windows during connection establishment.
• Flow Control ensures that message processing does not overwhelm any of the involved parties.
• This feature fits right into one the main goals of MQTT 5 - providing increased flexibility and transparency.

Learn everything about MQTT v5

This was the last part of this series. We hope you enjoyed our deep dive into all of the new MQTT 5 features. If you would like to join us, sign up for our newsletter to get regular updates and ensure that you don’t miss a post.

About Florian Raschbichler

Florian serves as the head of the HiveMQ support team with years of first hand experience overcoming challenges in achieving reliable, scalable, and secure IoT messaging for enterprise customers.
Contact Florian