Like a kid at Christmas, IoT nerds everywhere can hardly contain their excitement for the upcoming release of the MQTT 5.0 connectivity protocol. For those of you who are past setting out cookies and carrots for the fat man and his deer and prefer to scrooge things up a bit, read on and learn about some of the exciting new features in MQTT 5.0.
Return Code on all ACKs
More information? Yes please. Who hasn’t attempted to debug a hard to reproduce problem only to wish the API provided more information in response? Answer – nobody. With the current draft of version 5.0 there are at least 9 potential return codes. Admittedly, one will have to hope that the implementer providing the return codes does so appropriately, but at least there is an infrastructure to allow useful information being returned with the message ACK. This will allow the quality of IoT systems to improve by helping to confirm the operation or assist in a debug effort.
Sometimes data can be provided at such a pace that packets start to be dropped, valuable info is lost, and the whole operation of our system can go sideways. How to cope? Slow down the messaging. Now the client and server can both, independently, specify the number of outstanding reliable messages they permit. Yep, quality of service (QoS) is improving for IoT. By having this feature present, the sender will be required to temporarily suspend messages in order to maintain the QoS for the receiver. This may result in dropped messages and information from the sender at some point when resources such as memory, buffer size, and power are in short supply, but it provides a mechanism to ensure an agreed upon level of quality.
Maximum Packet Size
Quick, name the number of times when you released software that you never had to add a feature to later? Survey says… nada, zilch, zero, the same number of victories the Hamilton Tiger-Cats can expect this year. As features are added the blobs of data passed between devices often grows. In the case of a remote device with limited resources, this could eventually cause complications. By allowing the receiver of data to specify the max packet size they will allow, they can impose reasonable limits on the sender of data. It also forces the implementers of connected devices to periodically revaluate what data truly adds value to the end operator of such systems.
Will Delay (aka I’m not dead yet)
When a device fails to send a message for a period of time and it is determined to be disconnected from the network, the broker creates one last publication from the sender called the Will Message. All subscribers could get this message to be notified that the subscription is no longer valid. The Will Message gets its name from “Last Will and Testament” because the publisher has effectively died. In MQTT 5.0, when the Will Message gets sent can be determined by the new feature of Will Delay. Suppose a sender of info has a Will Delay of 5 seconds. If the sender becomes disconnected for 4 seconds, then reconnects, the Will Message is never sent by the broker. This allows subscribers to behave as though the connection was never interrupted. When one is in a situation where a device may be frequently entering and exiting areas of network coverage it prevents unnecessary and frequent toggling between notifying subscribers of a device being connected and disconnected. This allows the entire system to operate more efficiently, save processor cycles, power, and provide a better overall experience.
These are just a few of the key features coming in the soon to be released MQTT 5.0 protocol. End consumers will benefit from the maturity and improvements of the infrastructure, as IoT systems continue to evolve.
Have an IoT project you are thinking about creating? Give us a call and we’ll make it a success.