What's New in MQTT 5 and Advantages over version 3.1

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 MQTT Server 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 for MQTT QoS Levels except 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 MQTT Quality of Service, 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 authorized 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.