#006 — Have you heard of MQTT 5 yet?
In this follow-up post to #004, we are going to take a look at what’s new with the MQTT5 spec, and in the process learn more low footprint communication protocols in general.
To start with, we first need to realise that this is not a minor update. We are going from 3.1.1 to 5 — which means that there are going to be breaking changes. It is important that one consider this especially when they have existing systems that rely on 3.1.1 and are not easily upgradable.
Scalability
It’s important to cater to the large cloud providers and scalability is right at the top of the list of concerns. Interestingly, Microsoft was a part of the design process for MQTT5 for the first time.
Load Balancing
Horizontally scaled applications can now easily subscribe to a topic using the $shared keyword. This makes it easy for multiple instances of the same applications to subscribe to a topic.
Reason codes
Optional reason codes at the application level mean that the client can actually figure out why a particular connection was refused or more. Reason Codes less than 0x80 indicate successful completion of an operation. The normal Reason Code for success is 0. Reason Code values of 0x80 or greater indicate failure.
Note that the list of reason codes is common across all packets — CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, DISCONNECT, AUTH, SUBACK and UNSUBACK.
The complete list of the reason codes can be found in the specification section 2.4.
Smaller footprint
The client can PUBLISH with a zero length string as the topic in which case the server assumes that the client wants to publish to the same topic as the one it was publishing to before this publish (wow that was a lot of publish-ing in one sentence).
This saves on precious bandwidth and makes a lot of sense especially for sensor and nodes which are in extremely remote locations and rely on an expensive network infrastructure.
Power to the Server
- Allow the server to send the keep alive value to the client
- Assign a client id to the server
- Allow disconnect to be sent from the server
- Allow the server to specify an alternative server — aka redirection
- Mention feature availability — backward compatibility
Clean session
In MQTT 3.1.1 and earlier, the value of the clean session flag would determine how the server treats a connection from a client who has had a conneciton with the server before.
The clean session flag has now been replaced by then clean start flag. To completely replace the functionality offered by the clean session flag (deleting session information and connection), we now also need a session expiry value in the CONNECT packet.
Elephant in the room
Let’s face it — the first question in everyones mind is why are we going from 3.1.1 to 5? What’s wrong with the number 4 — apart from it being a very poorly rated from 2011?
So the MQTT connect packet has a byte indicating the version of the protocol the connection in question is using. Having a field for protocol version is pretty common, so not a big surprise. But with MQTT, we only have one byte to do so. With MQTT 3.1, the byte will have the value of 3. But with MQTT 3.1.1, the byte had the next available value of 4. Moving forward, we could either have the representation of the version mismatch the version number itself, or skip a version number. To keep things simple, the nice folks at MQTT decided to do the latter.
This is a fun tidbit, and gives us a peek into the things that one needs to consider when designing a protocol — like having a byte for major and minor version. Moving right along.
Final Thoughts
One of the recurring themes that I have realised while reading about the new spec is the focus on giving the server/broker more power. There are a lot more things that the broker has a say in. This feels like a good thing because it most likely means less complexity in the firmware — which is undoubtedly more difficult to maintain given the remote nature of it.
Please note that I haven’t listed down all the changes that are part of the new spec, but only some which I found most interesting. To really get a more clearer picture, I highly recommend one go through the MQTT5 spec!
Further Reading
There’s quite a few nice blog posts about the changes to the MQTT spec in version 5. Some of the ones that I have referred to are
