What’s new in MQTT 5 and Why you should adopt it today?
by Ponlakshmi
Today, the MQTT protocol is the most widely used and well-received TCP/IP IoT protocol in the world. It’s no surprise that the protocol’s widespread adoption has resulted in a high demand for further development of the MQTT specification. MQTT 5 attempts to meet this demand. In Manufacturing systems & logistics fields, and the smart home application, as well as enterprise IoT applications and mobile applications, are all popular MQTT v5 use cases.
MQTT 5 features overview
The new features in MQTT version 5.0 are intended to accomplish the following objectives:
Large-scale system performance: The communication between thousands, if not millions, of devices is now more streamlined. There are no protocol constraints, but MQTT 5 an appropriate architecture is required to organize these many devices.
Reporting of errors: The return code in the MQTTv5.0 protocol has been renamed to a reason code, which can indicate a wider range of failures.
Common interactions are implemented: The current version has standardised the many ways devices interact with one another. The system now includes the ability to define the capabilities of participating devices and how they respond to queries.
Extensibility mechanisms have been included: Custom properties can now be specified, as well as the content type or payload format.
Better Support: Particularly for smaller users who want to use this latest protocol version to increase their productivity.
How MQTT 5 is different from MQTT 3?
MQTT v5.0 differs from MQTT 3 in various aspects, showcasing advancements in communication protocols and fundamental changes in the way sessions, message transmission, and subscription management are handled. These distinctions contribute to a more evolved and versatile messaging protocol compared to its predecessor.
Below are the advancements in MQTT 5 :
- It introduces the session expiry interval. This allows the clients to set a maximum allowable time for a session, enhancing session management capabilities.
- The 'will delay interval' feature enables clients to specify a time delay before sending the last will & testament message. This provides more nuanced control over message transmission timing.
- Unlike MQTT v3.1, MQTT 5 offers a 'message expiry interval' feature. This allows clients to manage the life-span of messages by setting specific time limits for their relevance.
- The "payload format indicator" enables clients to specify payload structure, fostering standardized data interpretation. Concurrently, the introduction of a "content type" attribute enhances information clarity, distinguishing it from MQTT 3.1.
- Topic aliases in MQTT 5 streamline communication. Clients can use concise aliases instead of full topic strings, minimizing data overhead.
- The 'response topic' feature enables a structured request-response model. Clients can expect replies on specified topics, enhancing communication flexibility.
- Using non-local publishing, the clients can choose not to receive the messages they publish.
- Clients enhance retained message control by specifying when & how to send or update retained messages.
- The subscription identifier serves the purpose of allowing the server to identify subscriptions. It also helps in tracking these subscriptions.
- Shared subscriptions provide increased flexibility. They do so through the incorporation of additional symbols and filtering features.
- Reason codes on all ACK messages in MQTT 5 provide clear indicators for message acknowledgment or rejection. This enhances communication transparency and error handling. It stands in contrast to previous versions.
- In MQTT 5.0, packets concerning disconnections can be sent from both the client & server sides, a capability absent in version 3.1.
- User properties in MQTT 5 allow the storage of values for various properties using keys.
- Both the MQTT client and server impose restrictions. These limitations include constraints on maximum packet size (number of bytes to broadcast) & maximum messages to be sent simultaneously. These restrictions apply either on the client or server side.
- Server redirect/reference are attributes facilitating the transfer of packets between brokers/servers.
A Technical Overview of MQTT 5’s New Features
Session Expiry
Detach the Clean Session flag into a Clean Start flag, which indicates that the session should begin without using an existing session, and a Session Expiry interval, which specifies how long the session should be retained after a disconnect. At disconnect, the session expiry interval can be changed. In MQTT v3.1, setting Clean Start to 1 and Session Expiry Interval to 0 is equivalent to setting Clean Session to 1.
Message Expiry
Message expiry is an optional component of the PUBLISH control packet. The Message Expiry Interval in the PUBLISH packet delivered by the Server to a Client must be set to the received value excluding the time the message has been waiting in the Server. The Publish Expiry Interval, which applies to both online and queued messages, is the duration of the publication in seconds. Allow for the setting of an expiry interval when a message is published.
Reason Code and Reason String
Include a reason code in all response packets. CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT, and AUTH are some examples. This allows the invoker to check whether the requested function was completed successfully. Most packets containing a reason code should now allow for an optional reason string as well. This is intended to be used for problem identification rather than parsing by the receiver.
Topic Alias
Topic alias in MQTT v5 allows you to use the pub-sub messaging model in a more flexible way. Topic aliases can effectively save both network and processing resources for messages repeatedly published to a finite collection of topics, especially at big volumes. It allows the topic name to be abbreviated to a small integer to reduce the size of the MQTT packet overhead. The Client and Server each specify the maximum number of topic aliases they will accept.
Server Disconnect
The server can send a disconnect message to the client along with a reason code in MQTT 5. Unlike MQTT 3.1, MQTT 5.0 allows messages about disconnections to be sent from both the client and the server. Allow the Server to send DISCONNECT to specify why the connection is being closed. If there were any issues with the server, it would just terminate the session.
Payload Format & Content type
When sending a PUBLISH message, another identifier/value pair is available. This is the indicator for the Payload Format. When a message is published, allow the payload format (binary, text) and a MIME style content type to be specified. These are forwarded to the message’s recipient.
Request / Response Configuration
Request/Response pattern provides the Response Topic and Correlation Data features in MQTT to allow response messages to be routed back to the request’s publisher. Also, give the Client the ability to get configuration information from the Server about how to build the response topics. This mechanism enables the implementation of a “business acknowledgement” functionality that is extensible, dynamic, and transparent.
Shared Subscriptions
With standard MQTT protocols, shared subscriptions are a wonderful way to distribute messages among several MQTT subscribers. In version 5, support for shared subscriptions was added, allowing for load-balanced subscription consumers. A reserved topic root named $share and a share name are used to group subscribers in shared subscriptions.
Subscription Identifiers
When subscribing, the client might specify a subscription identifier. When you successfully create or edit a subscription, the broker will generate and store the mapping relationship between this subscription and the subscription identifier. Allows a numeric subscription identifier to be given on a SUBSCRIBE and returned when the message is delivered. This enables the Client to determine which subscription or subscriptions were responsible for the delivery of the message.
Subscription Options
Subscription options should be defined primarily for message gateway applications. There’s also a noLocal option for not sending messages from this Client, as well as options for how to handle retained messages on subscription. To customize the server behaviour, you can use more subscription options in MQTT v5.
Flow Control
Allow the Client and Server to select the amount of outstanding reliable messages (QoS>0) that they will accept separately. To stay within this quota, the sender pauses sending such messages. This is used to limit the rate at which reliable communications are sent and the number of messages in flight at any given time.
User Properties
Most packets should have User Properties. Client applications define the user properties on PUBLISH, which are included with the message. The Server sends the user properties on PUBLISH and Will Properties to the message receiver. The Server implementation defines the user properties on the CONNECT, SUBSCRIBE, and UNSUBSCRIBE packets. The sender defines the user characteristics on CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, and AUTH packets, and each sender implementation is unique. MQTT does not define the meaning of user properties.
Maximum Packet Size
Allow the Client and Server to declare the maximum packet size they can support independently. Sending a larger packet by the session partner is an error. This property must not be sent if it will raise the size of the PUBACK packet over the receiver’s Maximum Packet Size.
Optional server feature availability
Define a set of features that the Server does not allow, and give the Server a reason to determine the Client about them. Maximum QoS, Retain Available, Wild card Subscription Available, Subscription Identifier Available, and Shared Subscription Available are some of the characteristics that can be specified this way. Using features that the Server has indicated are not available is an error for the Client.
In previous versions , a Server could refuse to implement a feature by declaring that the Client is not authorised to use it. When the Client utilises one of these features anyhow, this feature allows such optional behaviour to be declared and adds corresponding Reason Codes.
Will Delay
Allow for a time delay between the end of the connection and the transmission of the will message. This is done so that the will message is not sent if the connection to the session is re-established. This allows for minor interruptions of the connection to occur without others being notified.
Server Keep Alive
Keep alive ensures that the broker-client connection is still active and that both the broker and the client are aware that they are linked. It allows the Server to provide the keep alive value the Client should use. This allows the Server to define a maximum keep alive time while still having the Client respect it.
Server Reference
The Client can utilise the Server reference to find another server to use. It allows the Server to specify a different server for CONNACK and DISCONNECT. This can be used to redirect or to perform provisioning.
Assigned Client Identifiers
Allows the Broker to assign Client IDs to clients in a consistent manner. Return the assigned ClientID in situations where the ClientID is assigned by the Server. The restriction that Server-assigned ClientIDs could only be used with Clean Session=1 connections is also lifted.
Why You need MQTT 5?
For most IoT use cases, the MQTT 5 specification has become the logical choice due to its advancements in security, reliability, flexibility, and performance. MQTT 5 not only overcomes the limitations of its predecessor but also lays the groundwork for future innovations. The adoption of MQTT 5 is expected to sky-rocket in the upcoming years across all sectors.
Are you looking to harness MQTT 5 for crafting IoT/IIoT applications that match your unique specifications?
To Learn more about the protocol,
