There's No Winner in the IIoT Protocols War
There's No Winner in the IIoT Protocols War
There's no winner in the IIoT protocols war. The IoT world is full of different scenarios, features needs, etc. that most of the time, the best solution is a hybrid one.
Join the DZone community and get the full member experience.Join For Free
Recently, I read this article about declaring MQTT as the winner of the IIoT (Industrial IoT) protocols war. But I have a completely different opinion on that and totally disagree with the author.
Don’t get me wrong — it’s not because I don’t like MQTT (anyone who knows me knows that I have done a lot of work around MQTT). It's actually because there is no winner in the IIoT protocols war.
The IoT world is so rich of different use cases, scenarios, features needs, and so on that most of the time, the best solution is a “hybrid” one that uses different protocols. This is true even if you focus on a specific IIoT space.
IoT has different communication patterns, and every protocol provides support for one or more of them in different ways. Sometimes, we have built-in support; sometimes, we need to do more work at the application level.
MQTT for Telemetry? But...
MQTT fits really well for telemetry because it’s mainly based on publish/subscribe. But at the same time, it has no flow control. What happens when the broker is overwhelmed by tons of messages at a high rate and it can’t dispatch such messages to the subscribers at the same pace? Most of the time, MQTT devices are tiny sensors that send data at a slow rate (i.e. every second) because they are battery-powered and use mobile connection so that they send a message, then go to sleep for few seconds, then wake up to send a new message. In this case, you don’t have a high rate, but if you have thousands (maybe even millions) of these devices, the broker is overwhelmed, as well; there is a burst of messages and it has to handle all of them.
AMQP doesn’t declare any specific supported pattern and it fits well for everything. Regarding telemetry (publish/subscribe), it provides flow control (even at different levels) so that the receiver node can stop the sender so that it has more time to process messages received up to the present moment.
Why More Complexity for Command and Control?
Moving to command and control, (request/reply), we see all of the MQTT limitations. In this case, you have to build something on top of the protocol infrastructure defining specific topics for the requests and the related replies and have each client — both subscribers (for receiving commands) and publishers (for sending replies). There is no correlation between request and reply; it’s all defined at the topic level (and/or using payload information).
With AMQP, even this pattern is supported natively. The requester has the ability to specify a “replyTo” address inside the message, saying to the responder that it expects to receive the reply on that address; even the correlation is supported at the protocol level thanks to message and correlation identifiers.
The real feature that defines the difference between AMQP and MQTT is that the former has message metadata (header, annotations, and so on) while the latter just has a payload (raw bytes). So all the features that it lacks for providing a different pattern from publish/subscribe need to be defined in terms of topic architecture and/or payload structure, so the complexity is moved at the application level.
If you want to read more about these differences (even with HTTP protocol), check out my article on the strengths and weaknesses of IoT communication patterns (it’s also part of the latest DZone IoT Guide).
Let’s Say Things as They Are
The mentioned article says some wrong things as well.
It's said that AMQP offers robust features like queuing; to be precise, there is no mention of queues in the AMQP specifications, but there is mention of containers, nodes, links, and so on. This is because AMQP doesn’t specify the network architecture in terms of brokers. Pay attention here — I’m speaking about AMQP 1.0, the only OASIS and ISO/IEC standard (against the AMQP 0.9, used in RabbitMQ). AMQP can be used for RPC without the “store and forward” mechanism (provided by brokers) and with only “direct” messaging. AMQP is a peer-to-peer protocol!
Regarding MQTT, it's also said that “an example of this optimization is its use of one byte keep alive packets.” But this is not true! It's 2 bytes. (I know I’m a little bit pedantic here.)
Finally, it’s not true that only MQTT can work without high availability and with low bandwidth. It’s true even for AMQP, considering the QoS (Quality of Service) levels it supports, as well.
With MQTT, each message carries the topic information. But this is not true with AMQP, where the address is specified one time on attaching the link.
When security and encryption come, the SSL/TLS overload minimizes all these differences so that a two bytes packet for keep alive becomes an even bigger message. In this case, it all depends on the computational resources that you have on your tiny device — the difference between protocols doesn’t matter.
As I stated earlier, there is no winner in the Industrial IoT protocols war. There are different use cases, scenarios, features needs, limitations, etc. that all point to the right choice — which sometimes means having multiple winners in one solution!
The good news about MQTT is that in the latest v5 specification they are addressing a lot of limitations of the current 3.1.1 version, adding some AMQP-like features.
So stay tuned — the war is endless!
Published at DZone with permission of Paolo Patierno , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.