MQTT 5 | Overview | What’s New | MQTT Features | MQTT 5.0

The MQTT protocol is the most popular and best received Internet of Things (IoT) protocol as of today supporting large scale use cases ranging from Connected Cars, Manufacturing Systems, Logistics, Defense, Use Cases to Enterprise Chat Apps, Mobile Apps and connecting constrained IoT devices. Of course, with huge amounts of production deployments, the wish list for future versions of the MQTT protocol grew bigger and bigger. In this post we talk about MQTT 5.0.

What is MQTT ?

MQTT used to stand for MQ Telemetry Transport, but is today referred to simply as MQTT and is no longer an acronym. It is an extremely simple and lightweight Publish/Subscribe messaging protocol invented at IBM and Arcom (now Eurotech) to connect restricted devices in low bandwidth, high-latency or unreliable networks.

If you’re new to messaging protocols you might wonder what Publish/Subscribe is all about. Have a look at our Publish/Subscribe section to get a quick idea. If you’d like a refresher on message queues, please have a look at the Message Queue section.

For more information visit this- MQTT | What is MQTT | MQTT in Depth | QoS | FAQs | MQTT Introduction

MQTT 5

The MQTT version 5 was released last year and a lot of people have been blogging and tweeting and talking about the merits of this protocol update. And there are tons of improvements! Here’s a list of some of them:

• Metadata via user properties: the ability to add extra information which can be inspected without having to parse and inspect the payload.
• Negative acknowledgements which makes it a lot easier for a client to understand what’s happening.
• Request/Response interactions.
• Provisioning features where brokers can tell clients to (re)connect to other broker instances.
• Fine grained retained messages handling.
• Differentiate received messages for which the subscriptions overlap using subscription identifiers.
• Enhanced authentication mechanism.
• Shared subscriptions to easily handle massive fan-in scenarios.
• Topic aliases which saves band-with when publishing messages.
• Use Message expiration to prevent clients from receiving stale/irrelevant information.

All above mention features are sorely needed. Some more than others. Negative acknowledgements allow for much easier debugging cycles when trying to understand why some client can’t connect, publish or subscribe to a specific topic by telling the client what actually happened. Shared subscriptions are needed to overcome the limitations of a single subscriber receiving more messages than it can handle. Topic aliases are great for those clients where the up-link is expensive and saving as many bits as possible is paramount.

Is it still lightweight?

MQTT 5 is same as MQTT 3.1.1. The only new packet is the AUTH packet which can be used to support SASL type authentication schemes. The rest flow as usual and the only case where more packets are flowing compared to MQTT 3.1.1 is to support the new features such as negative acknowledgements where earlier the client would just be disconnected.

The biggest change on the protocol level is the addition of properties which (for most) packets are optional. Properties are a list of key-value pairs which is used to support many of the new features introduced in the protocol. For instance topic aliases, message expiration intervals, enhanced authentication methods and data, and metadata (user properties) are all implemented as specific properties on the various packets.

On the wire this means that packets can contain extra optional data that only has to be parsed if it is there. The additional extra computational overhead is therefore to check if optional data is present or not, and if so, to parse it.

The extra work the parser has to do is extremely little and would not be noticeable on small scale MQTT deployments and even on large scale deployments it would not be expected to have any significant impact.

So MQTT 5 basically provides a lot of new features while making sure the computation and band-with cost is effectively zero if they aren’t used!

Recommended: MQTT Servers/Brokers | MQTT Public Brokers List

Broker and client library perspective

Compliant client libraries and brokers have to implement all these new features in all their glory and complexity. Fortunately most people don’t have to worry about this as a bunch of great MQTT 5 compliant client libraries are already in development! For instance the Eclipse Paho C, Go, and Java clients are well under way and the highly popular Mosquitto broker has also announced MQTT 5 support by August 2018.

You may like also:

• How To Create Secure MQTT Broker
• MQTT Servers/Brokers
• MQTT Products (that use MQTT)
• MQTT Public Brokers List
• IoT Data Protocols
• Setting up Authentication in Mosquitto MQTT Broker
• VerneMQ – Clustering MQTT for high availability and scalability
• How To Install VerneMQ on UbunTu, RHEL, Docker, Debian and Cent OS

Buy now : Raspberry PI 3 Model B+ Motherboard