6 facts why it's worth upgrading to the brand new MQTT 3.1.1 version

The long-awaited MQTT 3.1.1 was finally released on October 30, 2014. While most of the improvements may seem small, they are in fact a huge step forward. This blog post will cover the main differences compared to the old MQTT 3.1 standard and will cover the most interesting facts about it.

3 years after the MQTT specification was released under a royalty free license, OASIS formed a technical committee to standardize MQTT with the help of many companies. After over 1 year of development, MQTT 3.1.1 is now finally out!

Noteworthy changes

In general, MQTT 3.1.1 is an improvement of the 3.1 specification with the goal to clarify ambiguities and be as much backwards compatible as possible. Some of the most demanded new features were included in this release, so this is more than just a maintenance release. Beside the clarifications and a complete rewrite of the old spec, there are some pretty interesting changes which are worth looking at:

Session Present Flag

If a client connects with a persistent session (which means he doesn’t use a clean session), an additional flag was introduced in the CONNACK message to indicate that the broker already has prior session information of the client like subscriptions, queued messages and other information. This is an important new feature which allows even more efficient communication. Now clients get feedback if the broker already has their subscriptions and they only need to subscribe to topics, if the flag is set to false.

Additional error code on failed subscriptions

Prior to MQTT 3.1.1, it was impossible for clients to find out if a subscription wasn’t approved by the MQTT broker, which could be the case when using fine-grained permissions for MQTT topics. The new spec changes that and added a new error (0x80) in the MQTT SUBACK message, so clients can react on forbidden subscriptions.

Anonymous MQTT clients

If your use case requires temporary or anonymous MQTT clients, it’s now possible to set the MQTT client identifier to zero byte length. The MQTT broker will assign a random client identifier to the client temporarily. This is especially useful when you publish-only clients which don’t need authorisation based on client-ids and where you aren’t interested in persistent sessions.

Immediate publishes or Burst MQTT messages without waiting for responses

A very interesting new feature for MQTT clients is the ability to send MQTT PUBLISH messages before waiting for a CONNACK response of the MQTT broker. This allows very tiny and constrained MQTT clients to CONNECT, PUBLISH and disconnect without handling the response from the MQTT broker. This is also very useful for burst-mode clients which just care about sending out data as much as possible without maintaining a TCP connection for long time. Of course sophisticated broker implementations don’t distribute the messages before checking if the client is actually allowed to publish to these topics.

Client IDs are now allowed to be HUGE

MQTT 3.1 had a limit of 23 bytes per Client id which was very inconvenient and led to many troubles e.g. when using UUIDs for client identifiers. Fortunately enterprise-grade brokers like HiveMQ already supported longer client IDs even for MQTT 3.1. With the removal of this artificial restriction, client IDs can now use up to 65535 bytes.

Other low level changes

• The protocol name in the CONNECT header changed from MQIsdp to MQTT. This spares two byte overhead and makes the protocol name more readable

• All String encodings are now consistently UTF-8.

• The protocol level byte was incremented from 3 to 4

• MQTT over websockets is now finally specified. The IANA identifier is mqtt. Of course this was already possible with HiveMQ with MQTT version 3.1

HiveMQ and MQTT 3.1.1

The awesome news is, that you can start using MQTT 3.1.1 TODAY. HiveMQ supports MQTT 3.1.1 since version 2.0 and was one of the first brokers which were fully MQTT 3.1.1 compatible, even months before the standard was officially released. Together with Eclipse Paho you can start using the new standard right now and profit from all the latest and greatest improvements.

Of course you can use MQTT 3.1 and MQTT 3.1.1 transparently with your IoT scenario, since all clients can communicate with each other, regardless if they already support the new specification. You can even use MQTT over websockets with MQTT 3.1 and 3.1.1. If you need a secure transport you can additionally use TLS. This allows to upgrade very smoothly to the new MQTT specification since you don’t need to update your old devices and clients if you don’t want to, but you can profit from the newest features and improvements for newly deployed clients.

Oh and by the way: Did you already sign-up for a notification when we launch the HiveMQ pay-as-you-go licensing which scales with your business?

We hope you enjoy the new MQTT version as much as we do! If you are interested in all the nitty gritty details, you can read the spec yourself tags here.