MQTT v5.0 in a nutshell
How does protocol version 5.0 differ from version 3.1.1?
tl;dr (Too long; didn’t read)
MQTT v5.0 introduces some new features and introduces foundational changes in comparison with MQTT v3.1.1.
In summary:
- New feature: User Properties
- New feature: Shared Subscriptions
- New feature: Payload Format Indicators
- New feature: Content Types
- New feature: Response Topic (Request-Response Pattern)
- New feature: Correlation Data (Request-Response Pattern)
- New feature: Response Information (Request-Response Pattern)
- New feature: Topic Aliases
- New feature: (AUTH packet)
- New feature: Flow Control
- Additional Reason Codes: Overall there are 128 reason codes now (MQTT v3.1.1 had 19 reason codes)
- CONNACK packet: Return codes for unsuportted features
- Changed feature: Clean Start (instead of MQTT v3.1.1 Clean Session)
Session Expiry Intervals
It’s possible to define a sessionExpiryInterval in the CONNECT package of a MQTT client. This allows to define a duration of time a client must be offline until the MQTT broker cleans up the session for this MQTT client. The MQTT v5.0 sessionExpiry + cleanStart replaces MQTT v3 cleanSession flag. MQTT v5.0 sessionExpiry > 0 and cleanStart = false equals MQTT v3 cleanSession = false. MQTT v5.0 sessionExpiry =0 and cleanStart = true → MQTT v3 cleanSession = true.
Message Expiry Intervals
It’s possible to define a messageExpiryInterval in PUBLISH packets. This allows to define the time in seconds after which a message gets deleted by the MQTT broker in case it is not delivered to subscribing MQTT clients. This situation may e.g. occur if subscribing clients are not reliably online.
An use case for message expiry intervals is e.g. if outdated messages in distributed systems with unreliable networks are not relevant. In a connected car scenario a traffic alert message is not interesting anymore after 1 or 2 hours. Whereas a message about a firmware update should not expire even in case a car is offline for some time e.g. while driving through a tunnel.
Improved client feedback
Improved client feedback allows the MQTT broker to let the MQTT clients know what optional features and to what extend features which are limited the broker supports.
Optional features are retained messages, wildcard subscriptions, shared subscriptions, subscription identifiers and topic aliases.
Features which are limited are max. Keep Alive, max. Session Expiry Interval, max. Packet Size, max. number of Topic Aliases the client is allowed to send and max. Quality of Service the client is allowed to use.
There have been introduced reason codes for the following MQTT packets: UNSUBACK, PUBACK, PUBREC, PUBREL, PUBCOMP, DISCONNECT. A new field called reason string has been introduced to complement reason codes. It allows to add an arbitrary, human readable string. The server can send DISCONNECT packets with reason code and reason string now. E.g. if the client exceeds the max. packet size the broker
An use case of improved client feedback is e.g. improved debugging.
Negative acknowledgements
If a client e.g. sends a PUBLISH packet which exceeds the max. packet size the broker can response with a PUBACK packet with reason string instead of simply sending a DISCONNECT packet like in v3.1.1.
An use case of negative acknowledgements is e.g. ensuring consistency across multiple MQTT deployments.
User properties
User properties are UTF-8 string key-value pairs which can be added to all MQTT packets expect from PINGREQ and PINGRESP. The purpose of user properties to enable extensibility. One use case is e.g. enabling message traceability by adding meta-information of the client to the messages it publishes.
Shared Subscriptions
Shared subscriptions allows MQTT clients to share the same subscription on the MQTT broker. With usual subscriptions each client receives a copy of a single message. Shared subscriptions act as kind of load balancing (“client load balancing”) where messages published on a single topic are received by several clients in an alternating manner. Shared messages are published on topics which comply to $share/GROUPID/TOPIC. It’s possible to combine shared subscriptions in combination with usual subscriptions. In the following animation the clients corresponding to the GROUPID group1 (group1 Client 1, group1 Client 2) are receiving messages in an alternating manner (using round robin based selecttion). In comparison the Client 1 and Client 2 not belonging to a group receive every message.
FOr more info about shared subscriptions refer to this blog post.
Payload Format Description
Packets which contain payload (CONNECT packet that contains a WILL, PUBLISH packet) can indicate with a byte value wether the payload is encrypted as “unspecified byte stream” or as “UTF-8 encoded payload”.
Content Type
Packets which contain payload (again, CONNECT packet that contains a WILL and PUBLISH packet) may identifies the kind of UTF-8 encoded payload. AAny valid UTF-8 string or MIME can be used.
The use case of Payload Format Description in combination with Content Type enables the creation and definition of, potentially industry-wide, standards for MQTT.
Response Topic (Request-Response Pattern)
This feature is major, cause it introduces an entirely new communication paradigm to MQTT: Request-Response Pattern based communication. It’s important to understand that the request-response based communcation in MQTT is different from client server based technologies. Instead of enabling tightly coupled, synchronous (blocking) 1-to-1 communication MQTT v5.0 enables loosly coupled, asynchronous (non-blocking) 1-to-many communication possible. A response topic is an optional UTF-8 string that is available in PUBLISH and CONNECT packets and represents the topics on which the responses from the receivers of the message are expected.
Correlation Data (Request-Response Pattern)
Correlation data is optional binary data that follows the Response Topic in Response topic based communication and makes it possible for the original sender of the request to handle asynchronous responses that can possibly be sent from multiple receivers.
Response Information (Request-Response Pattern)
The Response Information property (request response information) is a boolean filed in the CONNECT packet and enables MQTT clients to request response information from the MQTT broker. This allows MQTT clients durin gconnection establishment time to get information about what topics in the topic tree are used for request-response kind communication.
In conjunction with Response Topic, Correlation Data, Response Information enables “end-to-end business acknowledgement” use cases.
Topic Alias
Topic Aliases are an integer value that can be used as a substitute for topic names. This protocol version feature is optional, MQTT broker and MQTT clients let know each other about if they support it or not during connection time.
Use cases for Topic Alias are in all cases where you want to send many small messages in real time with long topic names, which is e.g. interesting for predictive maintenance.
Enhanced Authentication
Enhanced authentication is enabled by a new AUTH packet and allows to implement advanced authentication standards using a challenge-response approach like the Salted Challenge Response Authentication Mechanism (SCRAM) or the Kerberos protocol.
Flow Control
The capabilities of client and brokers w.r.t. capabilities for processing in-flight messages (here, PUBLISH packets with a Quality of Service of one or two that has not yet been acknowledged) is different for MQTT clients as well as MQTT brokers. A MQTT client in an embedded device is less powerful than a MQTT client in an embedded single board computer. Different MQTT brokers differ in processing capabilities as well. During connection establishment clients can set a Receive Maximum (max. number of unacknowledged PUBLISH messages the client can receive) in the CONNECT packet. The broker reponds with Receive Maximum (max. number of unacknowledged PUBLISH messages the broker can receive) in the CONNACK packet.
Use case of Flow Control is the handling varying processing capabilities of MQTT clients and MQTT brokers.
