The most hilarious thing about MQTT is not mentioned. Look at the Quality of Service (QoS) parameter [1]. It has three levels, and the highest guarantee is “Exactly once (assured delivery)”. If someone designs a protocol for a highly distributed system and offers you this option, you know that you can safely discard the protocol and use something else (it is generally impossible to make such a guarantee). In a highly distributed system, error handling is the secret sauce. You can’t just delegate that to some magical mechanism that “guarantees” your delivery (most likely with blind retries). You can’t just live in blissful ignorance of the ugliness of network problems or failing devices. Your software on each device in the network needs to handle all these error states and respond accordingly. I personally think that MQTT brings little to the table that actually addresses the problems of a highly distributed system.
The first point was also pretty weak imo. The author basically wants MQTT to adopt a structured format instead of bytearray, which is going to expand the spec massively. And schema conflicts are still possible. There is no magic bullet to data interop.
They said it was the only way to have encryption, which is wrong. Since MQTT just passes around bytes, you can use whatever encrytion you want to encrypt the message you publish. TLS is one of the easiest for key negotiation, and most mqtt implementations offer that option probably because TLS is pretty common everywhere else.
The most hilarious thing about MQTT is not mentioned. Look at the Quality of Service (QoS) parameter [1]. It has three levels, and the highest guarantee is “Exactly once (assured delivery)”. If someone designs a protocol for a highly distributed system and offers you this option, you know that you can safely discard the protocol and use something else (it is generally impossible to make such a guarantee). In a highly distributed system, error handling is the secret sauce. You can’t just delegate that to some magical mechanism that “guarantees” your delivery (most likely with blind retries). You can’t just live in blissful ignorance of the ugliness of network problems or failing devices. Your software on each device in the network needs to handle all these error states and respond accordingly. I personally think that MQTT brings little to the table that actually addresses the problems of a highly distributed system.
[1]: https://en.wikipedia.org/wiki/MQTT#Quality_of_service_(QoS)
This is what QoS levels 1-2 are for. The broker queues the messages, and the device receives them when it finally logs on.
I mean, there’s plenty of things wrong with MQTT, but this article is pretty weak, imo
The first point was also pretty weak imo. The author basically wants MQTT to adopt a structured format instead of bytearray, which is going to expand the spec massively. And schema conflicts are still possible. There is no magic bullet to data interop.
i doubt TLS is mandatory in MQTT - i’ve seen implementations that fit in microcontroller. if you dont need encryption - dont use it.
They said it was the only way to have encryption, which is wrong. Since MQTT just passes around bytes, you can use whatever encrytion you want to encrypt the message you publish. TLS is one of the easiest for key negotiation, and most mqtt implementations offer that option probably because TLS is pretty common everywhere else.
To be fair, AWS IoT forces TLS.
That might be true but I’ve been using MQTT on and off for years and had never even heard of AWS IoT.