4 ms·

MQTT is interesting for IoT devices. Theses devices are low power, low memory, low speed, may have intermittent connections. The alternative to MQTT wouldn't b

by dwild 7y ago

MQTT is interesting for IoT devices. Theses devices are low power, low memory, low speed, may have intermittent connections. The alternative to MQTT wouldn't be HTTP or WebSockets, but actual sockets. MQTT is simple to implements and doesn't require much performance. Many of its implementations don't support its QoS feature that retries because the embedded processor doesn't have enough memory.

noobiemcfoob 7y ago
Both MQTT and HTTP are built on top of TCP sockets. A HTTP client can be implemented by hand with just a few examples in a few hours. I was unable to do the same with MQTT.
- dwild 7y ago
  Sure an HTTP client can be done, but you won't get the functionalities of MQTT and you'll have to support it yourself. MQTT is always on and it's bidirectional. The client can both listen to the server and talk to it. You sure can do that using some kind of push/pull over HTTP but that's going to be costly. You can sure do HTTP long polling, but that's most probably contains code smell. MQTT can be used simply to broadcast something, which is quite useful in the IoT world. You got a data that has changed, another client can easily get it and do something with it (either log it, show it, or change its behaviour based on it). Again something that you'll have to implements over HTTP. > A HTTP client can be implemented by hand with just a few examples in a few hours. If an implementation for it already exists (and most likely than not it does) you are better of with using it than rewriting it. Sure you can't do it in hours, but MQTT is simple enough that there's already an implementation for you somewhere. Though seeing this source code, I'm pretty sure it can be pulled off in hours still [1]. [1] https://github.com/knolleary/pubsubclient/blob/master/src/PubSubClient.cpp https://github.com/knolleary/pubsubclient/blob/master/src/Pu...
  - noobiemcfoob 7y ago
    This is a much better argument than your first comment. For a persistent connection, you might want to move from HTTP to WebSockets, which also brings the bidirectional quality and some more of the pub/sub qualities. Though WebSockets' complexity compared to just HTTP is similar to MQTT. Being able to implement the protocol yourself is less something I would do in production and more a comment on how easy a protocol might be to grok. I wouldn't expect to implement my own WebSockets client. So this and the relative overlap of features puts MQTT and WebSockets in the same bucket for me (far more so than MQTT and a raw socket). Summarizing my views: MQTT seems as opaque as WebSockets without the benefits of being built on a very common protocol (HTTP) and being used in industries beyond just IoT. The main benefits proponents of MQTT argue for (low bandwidth, small libraries) don't seem particularly true in comparison to HTTP and WebSockets.
    - dwild 7y ago
      > built on a very common protocol (HTTP) and being used in industries beyond just IoT. For use case beyond IoT, sure use everything else, but MQTT is great specifically for IoT. It's like saying x86 is better than others 32 bits architectures used by microcontroller because it's used in industries beyond embedded. What is used in embedded make sense for embedded only. If your needs are beyond that, go beyond. > I wouldn't expect to implement my own WebSockets client. So this and the relative overlap of features puts MQTT and WebSockets in the same bucket for me (far more so than MQTT and a raw socket). I wouldn't consider even implementing a WebSockets client. I would consider porting the 600 lines of that library I linked though. Would you consider porting that librarie instead [1]. > don't seem particularly true in comparison to HTTP and WebSockets. I use MQTT over my ESP8266 devices. That thing has 96 KB of RAM and 4 MB of flash memory. Sure Websocket can works on it, sure you can write an HTTP server on it, but in comparison, the library I linked is 600 lines of code, is simple to use and does everything that is needed of IoT really simply. Even if you were to try to replicate that in WebSocket, you would still have to add a way to broadcast that information easily instead of simply having another client that subscribes to the same server and listen to the topic you publish to. [1] https://github.com/Links2004/arduinoWebSockets/tree/master/src https://github.com/Links2004/arduinoWebSockets/tree/master/s...

by dwild 7y ago

noobiemcfoob 7y ago

Both MQTT and HTTP are built on top of TCP sockets. A HTTP client can be implemented by hand with just a few examples in a few hours. I was unable to do the same with MQTT.

dwild 7y ago
Sure an HTTP client can be done, but you won't get the functionalities of MQTT and you'll have to support it yourself. MQTT is always on and it's bidirectional. The client can both listen to the server and talk to it. You sure can do that using some kind of push/pull over HTTP but that's going to be costly. You can sure do HTTP long polling, but that's most probably contains code smell. MQTT can be used simply to broadcast something, which is quite useful in the IoT world. You got a data that has changed, another client can easily get it and do something with it (either log it, show it, or change its behaviour based on it). Again something that you'll have to implements over HTTP. > A HTTP client can be implemented by hand with just a few examples in a few hours. If an implementation for it already exists (and most likely than not it does) you are better of with using it than rewriting it. Sure you can't do it in hours, but MQTT is simple enough that there's already an implementation for you somewhere. Though seeing this source code, I'm pretty sure it can be pulled off in hours still [1]. [1] https://github.com/knolleary/pubsubclient/blob/master/src/PubSubClient.cpp https://github.com/knolleary/pubsubclient/blob/master/src/Pu...
- noobiemcfoob 7y ago
  This is a much better argument than your first comment. For a persistent connection, you might want to move from HTTP to WebSockets, which also brings the bidirectional quality and some more of the pub/sub qualities. Though WebSockets' complexity compared to just HTTP is similar to MQTT. Being able to implement the protocol yourself is less something I would do in production and more a comment on how easy a protocol might be to grok. I wouldn't expect to implement my own WebSockets client. So this and the relative overlap of features puts MQTT and WebSockets in the same bucket for me (far more so than MQTT and a raw socket). Summarizing my views: MQTT seems as opaque as WebSockets without the benefits of being built on a very common protocol (HTTP) and being used in industries beyond just IoT. The main benefits proponents of MQTT argue for (low bandwidth, small libraries) don't seem particularly true in comparison to HTTP and WebSockets.
  - dwild 7y ago
    > built on a very common protocol (HTTP) and being used in industries beyond just IoT. For use case beyond IoT, sure use everything else, but MQTT is great specifically for IoT. It's like saying x86 is better than others 32 bits architectures used by microcontroller because it's used in industries beyond embedded. What is used in embedded make sense for embedded only. If your needs are beyond that, go beyond. > I wouldn't expect to implement my own WebSockets client. So this and the relative overlap of features puts MQTT and WebSockets in the same bucket for me (far more so than MQTT and a raw socket). I wouldn't consider even implementing a WebSockets client. I would consider porting the 600 lines of that library I linked though. Would you consider porting that librarie instead [1]. > don't seem particularly true in comparison to HTTP and WebSockets. I use MQTT over my ESP8266 devices. That thing has 96 KB of RAM and 4 MB of flash memory. Sure Websocket can works on it, sure you can write an HTTP server on it, but in comparison, the library I linked is 600 lines of code, is simple to use and does everything that is needed of IoT really simply. Even if you were to try to replicate that in WebSocket, you would still have to add a way to broadcast that information easily instead of simply having another client that subscribes to the same server and listen to the topic you publish to. [1] https://github.com/Links2004/arduinoWebSockets/tree/master/src https://github.com/Links2004/arduinoWebSockets/tree/master/s...