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)

in comparison with MQTT v3.1.1.

In :

  • 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. .

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. .

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. .

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. .

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. .

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.

Image for post
Image for post

FOr more info about shared subscriptions refer to this .

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 .

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 can be used.

The use case of Payload Format Description in combination with Content Type enables the .

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 .

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. .

Enhanced Authentication

Enhanced authentication is enabled by a new AUTH packet and allows to .

Image for post
Image for post

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.

Software Developer for rapid prototype or high quality software with interest in distributed systems and high performance on premise server applications.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store