4 ms·

Can someone justify MQTT over HTTP and WebSockets? Before you jump down my throat, I've used all three protocols to a fair degree. MQTT was the most painful, a

Can someone justify MQTT over HTTP and WebSockets? Before you jump down my throat, I've used all three protocols to a fair degree. MQTT was the most painful, and without strong justification, what's the point? I always read a bandwidth usage justification, but if that's the case, someone should be able to tell me the number of overhead bytes saved using MQTT over WebSockets.

Rldm840 7y ago
A quick comment based on our experience. We have been providing a proprietary messaging server based on WebSockets and HTTP Streaming for many years now, mainly used for financial trading, online betting, and aerospace. The increased popularity of MQTT in recent years pushed us to find some good points of contact between MQTT and our well established practices to deliver real-time data through the Internet. Simply tunneling MQTT over WebSocket didn't seem to be enough in some scenarios (perhaps corner cases, perhaps not, we don't know yet). In particular, what is completely lacking in MQTT (and in MQTT over WebSockets) is the ability to throttle and resample the data on the fly based on the available bandwidth. To make a long story short, we decided to "add" this and other features to MQTT by creating a gateway that transparently remaps MQTT over our proprietary but open protocol (TLCP). The result is a solution that exposes very standard MQTT API (Mosquitto-like), but is much more Internet-friendly than MQTT over WebSockets (both for throttling and other reasons, which I don't list here to keep it short). In this Dzone article we explain a bit more about adaptive throttling: https://dzone.com/articles/mqtt-throttling-data https://dzone.com/articles/mqtt-throttling-data
deleted 7y ago
[deleted]
googlesux 7y ago
Publish and subscribe method ez for small scale devices
Arnavion 7y ago
(At first I thought you were asking about MQTT-over-websockets, but you're actually asking about MQTT vs websockets.) I believe MQTT implementations tend to be smaller, which is why it's popular for IoT devices. Both HTTP and WebSockets are much more diverse specs, so a generally available implementation might have a lot of features the device never uses but still occupy disk and memory (multiple kinds of headers and their semantics, data encodings, etc).
theflyinghorse 7y ago
Decoupling between publishers and subscribers is the biggest one. Being able to store messages while consumer is down. Last will messages are very convenient. Ability to authorize on topic level. All of that is very useful in my use case (networking and IoT equipment in the middle of nowhere in rough conditions that can go down a fair amount).
deleted 7y ago
[deleted]
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.

Rldm840 7y ago

A quick comment based on our experience. We have been providing a proprietary messaging server based on WebSockets and HTTP Streaming for many years now, mainly used for financial trading, online betting, and aerospace. The increased popularity of MQTT in recent years pushed us to find some good points of contact between MQTT and our well established practices to deliver real-time data through the Internet. Simply tunneling MQTT over WebSocket didn't seem to be enough in some scenarios (perhaps corner cases, perhaps not, we don't know yet). In particular, what is completely lacking in MQTT (and in MQTT over WebSockets) is the ability to throttle and resample the data on the fly based on the available bandwidth. To make a long story short, we decided to "add" this and other features to MQTT by creating a gateway that transparently remaps MQTT over our proprietary but open protocol (TLCP). The result is a solution that exposes very standard MQTT API (Mosquitto-like), but is much more Internet-friendly than MQTT over WebSockets (both for throttling and other reasons, which I don't list here to keep it short). In this Dzone article we explain a bit more about adaptive throttling: https://dzone.com/articles/mqtt-throttling-data https://dzone.com/articles/mqtt-throttling-data

deleted 7y ago

[deleted]

googlesux 7y ago

Publish and subscribe method ez for small scale devices

Arnavion 7y ago

(At first I thought you were asking about MQTT-over-websockets, but you're actually asking about MQTT vs websockets.) I believe MQTT implementations tend to be smaller, which is why it's popular for IoT devices. Both HTTP and WebSockets are much more diverse specs, so a generally available implementation might have a lot of features the device never uses but still occupy disk and memory (multiple kinds of headers and their semantics, data encodings, etc).

theflyinghorse 7y ago

Decoupling between publishers and subscribers is the biggest one. Being able to store messages while consumer is down. Last will messages are very convenient. Ability to authorize on topic level. All of that is very useful in my use case (networking and IoT equipment in the middle of nowhere in rough conditions that can go down a fair amount).

deleted 7y ago

[deleted]

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.