by Jesmi | Mar 14, 2022 | MQTT | 0 comments
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.
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.
MQTT v5.0 is MQTT 3.1‘s successor. Most importantly, MQTTv5.0 does not support backward compatibility (like v3.1.1). As there are so many new items introduced, current implementations must be revisited.
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 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.
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 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.
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.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
For most IoT use cases, the MQTT 5 specification has become the logical choice. MQTT 5’s new features successfully solves version 3’s limitations while also opening the path for future development. The protocol adoption is expected to sky-rocket in the coming years across all sectors, including industrial, automotive, critical infrastructure, logistics, smart cities, and so on. MQTT is on the edge of becoming the industry standard for all things connected to the Internet of Things.
Do you desire to use MQTT 5 to develop IoT / IIoT applications that meet your specific requirements?
To Learn more about the protocol,
Please take a moment to fill this form
