Introduction
MQTT[1] 5.0, launched in March 2019 by OASIS (Organization for the Advancement of Structured Information Standards), is a significant upgrade from the MQTT 3.1.1 version released in 2014.
As a messaging protocol specifically designed for the Internet of Things (IoT) and Industrial IoT, it was previously introduced in ‘MQTT, Friend of Weak Networks’, so we will not elaborate further.
This version not only retains the useful features of the previous version but also adds new characteristics to better support the current IoT application needs.
Overview
Development History
MQTT was developed by IBM in the late 1990s for monitoring oil pipelines via satellite networks.
The release of MQTT 3.1.1 in 2014 was a major milestone, as it was more stable and comprehensive compared to earlier versions, and it quickly gained widespread adoption in the IoT sector.
With the advancement of the IoT industry, new application demands have continuously emerged. To address these changes, MQTT 5.0 was launched in 2019 with more new features.
Why No Version 4.0?
It is said that the new version’s significant upgrades and numerous new features warranted a new version number, hence the direct use of 5.0 to emphasize the substantial improvements of this version.
Main Changes
Backward Compatibility
Compatible with all features of version 3.1.1
New Features Added
The main new features include enhanced authentication, message and session expiration times, topic aliases, shared subscriptions, and reason codes.
Below, we will explain each in detail 👇
Detailed Explanation of New Features
Enhanced Authentication: No More Direct Password Transmission
Remember the previous article on optimizing the MQTT architecture based on 3.1.1, which mentioned that 3.1.1 could authenticate via username/password or token? This method is called simple authentication, which can be easily compromised or intercepted.
MQTT 5.0 supports the SCRAM (Salted Challenge Response Authentication Mechanism) authentication mechanism, where the client does not send the password directly.
The client first requests the server with the username, and the server verifies the username before providing parameters such as a nonce, salt, and iteration count. After obtaining the salt, the client encrypts the password with the salt and requests the server again.
The general process is as follows:
SCRAM uses a nonce and iterative algorithms to ensure that each authentication process is unique, preventing replay attacks. Information intercepted in a single instance is rendered useless.
Topic Aliases: No Need to Call Me by My Full Name Every Time
The MQTT protocol was designed to reduce communication overhead for lightweight and low-power applications, and topic aliases further streamline this process.
Topic aliases allow the topic to be given a nickname after the first message is sent, further reducing overhead.
In previous versions, the client had to specify a topic each time it sent a message, for example, “heliansheng-qianbanshiren-wushihong”. With topic aliases, this can be shortened to an alias like “1”, so subsequent messages only need to include “1”, which is a significant saving.
Shared Subscriptions: Load Balancing for Subscribers
Multiple subscribers can share the same subscription, with a message being received by only one of the subscribers.
The shared subscription feature is particularly suitable for scenarios requiring load balancing and high availability.
For example, in a smart factory, sensor devices send temperature and humidity data to the server via MQTT. Multiple data processing service instances on the backend share the same subscription topic. This way, each service instance can handle a portion of the messages, reducing the load on a single instance while improving system reliability.
Reason Codes: No More Guessing the Cause of Issues
Version 5.0 introduces the Reason Code and Reason String features, providing more detailed error information and diagnostic data to help developers and system administrators better understand and resolve communication issues.
When I previously used 3.1.1, I encountered issues such as occasional disconnections and connection failures, which were frustrating to troubleshoot due to the lack of error messages, often requiring guesswork and wasting time.
In 5.0, if certain clients frequently disconnect, checking the server logs reveals a reason code of <span>0x9D</span> (session takeover) and a reason string of “Session taken over by another client.” This makes it easier to identify that multiple clients are likely using the same client ID to connect to the server. That simplifies troubleshooting.
Session Expiration Time: Sessions Won’t End Immediately Upon Disconnection
In previous versions, if a client disconnected, the session would either end immediately or remain indefinitely, with no configurable time. Version 5.0 supports configurable session retention times.
Comparison with 3.1.1
Although version 5.0 offers more comprehensive and powerful features, many enterprises and users still use version 3.1.1, which is an earlier and still quite “sufficient” version.
For developers, 3.1.1 is faster and easier to implement, and many scenarios may not require the features of 5.0, allowing for a quick deployment of a 3.1.1 version.
Moreover, the ecosystem for 3.1.1, including documentation, libraries, and community support, is more mature due to its wider usage. It’s similar to how Kubernetes once stated it would not support Docker, yet most online resources for deploying or troubleshooting Kubernetes still reference Docker.
Should You Upgrade?
Whether to upgrade depends on your specific use case and requirements. Considerations include whether the new features in 5.0 are essential, whether the upgrade will impact existing services, and whether clients can be updated simultaneously.
Additionally, consider whether the new features might affect business or security aspects, such as 5.0 allowing clients to send custom data to the broker.
Conclusion
As mentioned above, while 5.0 has significantly improved security, if your project primarily focuses on basic publish/subscribe functionality and has low demand for new features, or if you need to maintain compatibility with existing MQTT 3.1.1 clients and servers, you can continue using MQTT 3.1.1.
However, if you are targeting financial-grade applications, upgrading to 5.0 is essential, and it is advisable to start preparations immediately.
References[1]
MQTT: https://mqtt.org/