Five Reasons to Upgrade to MQTT 5

MQTT has become a popular protocol for connecting Internet of Things (IoT) devices to the cloud. MQTT was originally developed in 1999, to monitor oil and pipelines over satellite networks. At the time, the need was for a protocol that was efficient for remote devices with limited sources of power, that had efficient bandwidth usage, and that was able to operate over unreliable network connections. When MQTT was developed, the term IoT hadn’t been coined, cloud computing wasn’t a thing, and the diverse set of Applications for IoT hadn’t emerged.

For these reasons, the MQTT protocol needed to be updated to address some of the missing features required to host MQTT on large-scale cloud platforms and to handle additional IoT Applications. In 2015/2016, work began within OASIS on a new version of the specification, called MQTT 5. In March 2019, MQTT 5 was ratified as an official OASIS standard.

There are a number of new features in MQTT, but there are 5 key features that improve the error handling, scalability, and flexibility of deployment MQTT systems.

Session and Message Expiry

MQTT 5 now allows for each session and message to specify a time limit. If a message is not delivered in a set period of time, it will be deleted. This can be very important for safety critical-Applications if a message needs to arrive within a certain period of time.

Shared Subscriptions

Shared subscriptions allow multiple MQTT client instances to share the same topic subscriptions from an MQTT broker. This feature is very useful if an MQTT client has been set up to stream MQTT data into a back-end enterprise system, like a database. Different MQTT clients sharing the same subscriptions can be deployed across different cluster nodes to help with scalability and high availability.

Negative Acknowledgements

An MQTT broker supporting MQTT 5 can now send what is called a negative acknowledgement to reject certain types of messages, such as maximum QoS, maximum message size, and unsupported features in the broker. Rejecting a message that exceeds a maximum message size is useful for identifying MQTT clients that might have become malicious.

Payload Format Indicators

MQTT has always been payload agnostic, but MQTT 5 now allows for the addition of payload format indicators, values binary, or text. This will make it easier for processing of the MQTT message.

User Properties

In addition to the payload format indicators, MQTT 5 messages can now include user properties that add a key-value property to the message header. These properties allow for application-specific information to be added to each message header.

Conclusion

The MQTT community is gradually including support for MQTT 5 to the various MQTT implementations, including Eclipse Paho, Mosquitto and HiveMQ. If you're considering using MQTT in your next IoT application, strongly consider using MQTT 5.