5 ms·

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 sa

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...
    - noobiemcfoob 7y ago
      > What is used in embedded makes sense for embedded only Certainly, with that attitude. Personally, I fight that mentality when I can. The reason to lean on technology that is used in multiple disciplines is to increase the pool of viable programmers. If it's the wrong tool, then it's the wrong tool. But otherwise use the tool that the most can use. On porting libraries...well, the WebSockets client I play with is only 60 lines. So, I don't know, you tell me: https://github.com/danni/uwebsockets/blob/esp8266/uwebsockets/client.py https://github.com/danni/uwebsockets/blob/esp8266/uwebsocket... And yeah, that's micropython (because I love inviting the wrath of embedded developers). But that will run on your ESP8266 just fine. I use the D1 mini :) You're definitely right on having to implement more of the pub/sub on your WebSockets server. I misspoke in saying WebSockets gives you those qualities.

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...
  - noobiemcfoob 7y ago
    > What is used in embedded makes sense for embedded only Certainly, with that attitude. Personally, I fight that mentality when I can. The reason to lean on technology that is used in multiple disciplines is to increase the pool of viable programmers. If it's the wrong tool, then it's the wrong tool. But otherwise use the tool that the most can use. On porting libraries...well, the WebSockets client I play with is only 60 lines. So, I don't know, you tell me: https://github.com/danni/uwebsockets/blob/esp8266/uwebsockets/client.py https://github.com/danni/uwebsockets/blob/esp8266/uwebsocket... And yeah, that's micropython (because I love inviting the wrath of embedded developers). But that will run on your ESP8266 just fine. I use the D1 mini :) You're definitely right on having to implement more of the pub/sub on your WebSockets server. I misspoke in saying WebSockets gives you those qualities.