MQTT, which stands for Message Queuing Telemetry Transport, is a lightweight messaging protocol designed for constrained devices and low-bandwidth, high-latency networks. It is particularly useful for remote connections where a small code footprint is required or network bandwidth is limited.
MQTT 5 is the latest version of the protocol, offering many improvements over its predecessors. New features include reason codes, session expiry intervals, topic aliases, user properties, subscription options, request/response features, and shared subscriptions.
We’ll explore these new features, explain how popular brokers and client SDKs are supporting MQTT 5, and some key considerations when migrating from MQTT 3.1.1 to MQTT 5.
Brief History and Evolution of MQTT 5
MQTT was first developed in the late 1990s by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Arcom (now Eurotech), to monitor oil pipelines over satellite networks. The initial version, MQTT v3.1, was designed to be lightweight and easy to implement, making it suitable for many IoT devices.
MQTT 3.1.1, an OASIS standard, was released in 2014, which included minor changes to the protocol to improve its clarity and interoperability. Its simplicity and efficiency in delivering messages over networks with limited resources led to its widespread adoption in IoT applications.
However, as the IoT industry evolved, so did the needs of its applications. This led to the development of MQTT 5, released in 2019, which introduced new features to address these changing needs. With its enhanced features, MQTT 5 is better equipped to handle the complex requirements of modern IoT applications.
7 New Features in MQTT v5
Reason Codes: Understanding Disconnections or Failures
Unlike its predecessors, MQTT 5 can provide a reason code for every acknowledgment packet, giving us a better understanding of why a disconnection or failure occurred. This improvement aids in troubleshooting and allows for more precise error handling.
For instance, if a client fails to connect to the server, the server will return a reason code explaining why the connection was unsuccessful. This could be due to a range of issues, from incorrect login credentials to a server being unavailable.
Session Expiry Intervals: Managing Session Lifetimes
This feature allows the client to specify how long the server should maintain its session after the client disconnects. In previous MQTT versions, a session either ended immediately upon disconnection or continued indefinitely.
With MQTT 5, you can define a specific period for which the session should be kept alive after disconnection. This provides greater flexibility in managing session lifetimes and conserves resources on the server.
Topic Aliases: Reducing Overhead in Message Headers
MQTT 5 introduces topic aliases to reduce the overhead in message headers. In previous versions, the topic name needed to be included in every message, leading to larger packet sizes.
With topic aliases, a short numeric alias can be assigned to a topic. This alias can be used in place of the full topic name in subsequent messages, significantly reducing the size of the MQTT header and conserving network bandwidth.
User Properties: Custom Metadata in MQTT Headers
This feature allows users to include custom metadata in the headers of MQTT packets. This can be particularly useful for applications that need to send additional information with their MQTT messages, such as the message’s timestamp, device location, or other application-specific data User properties provide greater flexibility and control over MQTT messaging.
Subscription Options: Granular Subscription Controls
MQTT 5 allows clients to specify how they want to receive messages for each subscribed topic. For instance, clients can now specify whether they want to receive retained messages for a particular subscription, or whether they want to receive messages even if they have the same QoS (Quality of Service) level as the subscription.
Request/Response: Allowing Clients to Reply to a Specified Topic
The request/response feature allows a client to specify a topic that the server can use to send a direct reply.
In earlier versions of MQTT, if a client wanted to send a response to a message, it had to publish the response to a topic, and the original sender had to be subscribed to that topic to receive the response. With MQTT 5’s request/response feature, communication between clients and servers becomes much more efficient and straightforward.
Shared Subscription: Load-Balancing Function for Subscribers
This feature allows multiple clients to share a subscription. When a message is published to a shared topic, the server distributes the message to one of the clients in the shared subscription, effectively load-balancing the messages.
This feature is particularly useful in scenarios where you have multiple instances of a service running, and you want to distribute the workload evenly among them.
Current Support of Broker and Client SDKs in MQTT 5.0
The MQTT 5.0 protocol has been well received by the IoT community, and numerous MQTT brokers and client Software Development Kits (SDKs) have added support for it. Major MQTT brokers have already implemented MQTT 5.0 features in their platforms, allowing users to leverage the new protocol’s benefits.
On the client SDK front, libraries like Paho, which have a broad user base, have added support for MQTT 5.0. This means developers can now utilize MQTT 5.0 features in their IoT applications. Other examples of client SDKs that support MQTT 5.0 are MQTT.js and MQTTnet.
Checklist for Migrating from MQTT 3.1.1 to MQTT 5
If you are currently using MQTT 3.1.1, it’s probably time to upgrade to MQTT 5. Here are some of the main things you should consider when making the move.
Update MQTT Brokers
Once you’ve evaluated your current infrastructure and decided to go ahead with the migration, the next step is to update your MQTT brokers. This involves installing the latest version of your MQTT broker that supports MQTT 5.0.
Upgrading your broker should be done with care, as it impacts all your MQTT clients. It’s advisable to first test the new broker in a non-production environment before rolling it out in production. Also, ensure that your broker’s configuration is updated as necessary to support the new features introduced in MQTT 5.0.
Update Client Libraries
After updating your MQTT brokers, the next step is to update your MQTT client libraries. Just like the broker update, you should perform this update in a non-production environment first. Also, ensure that your application code is updated to handle the new MQTT 5.0 features. Take into account that this might involve some code refactoring.
Address Security
While MQTT 5.0 brings several improvements, it also introduces new security considerations. For example, with the new user property feature, clients can now send custom data to the broker.
While this is a powerful feature, it can be exploited if not used correctly. Therefore, it’s important to assess all the new features from a security perspective.
Some of the steps you can take to address security include using the new enhanced authentication feature for stronger security, limiting the user properties that clients can send to only what’s necessary, and continuously monitoring for any suspicious activities.
Monitor after Migration
Finally, after you’ve migrated to MQTT 5.0 and implemented its features, it’s important to continuously monitor your system. Monitoring should not just be limited to technical aspects like message delivery or client connections.
You should also monitor the usage of the new MQTT 5.0 features in your applications. This will give you insights into how these features are enhancing your applications and where further improvements can be made.
Latest IoT News
