WebSocket is good for browsers, but is it optimal for embedded connectivity?
WebSocket was initially created in order to provide browser a way to establish a full-duplex communication channel. It's the TCP socket of Web, as ordinary browser can not open a native TCP socket. WebSocket can be used for connectivity of embedded devices as well, but is it optimal for that purpose?
I have been looking for alternative solutions, but haven't found a satisfying one, until I got informed about MQTT. The acronyme stands for Message Queue Telemetry Transport, a protocol initially invented by IBM. The aim of the protocol can be expressed as follows:
"MQTT stands for MQ Telemetry Transport. It is a publish/subscribe,
extremely simple and lightweight messaging protocol, designed for
constrained devices and low-bandwidth, high-latency or unreliable
networks. The design principles are to minimise network bandwidth and
device resource requirements whilst also attempting to ensure
reliability and some degree of assurance of delivery. These principles
also turn out to make the protocol ideal of the emerging
“machine-to-machine” (M2M) or “Internet of Things” world of connected
devices, and for mobile applications where bandwidth and battery power
are at a premium."
IBM and IoT, doesn't immediately sounds like they have anything in common. What does the Big Blue have to do here? Even if IBM is behind the protocol, it's not a single source proprietary stuff. Protocol specifications are published publicly, and a technical committee of OASIS organization is on it's way to standardize it. Not only to have an open specification, but to have an open standard, to emphasis open APIs.
What makes MQTT more suitable than WebSocket or HTTP REST API in context of Embedded Systems?
- MQTT provides publish/subscribe mechanism already in protocol level
- MQTT provides Quality of Service policy
- MQTT introduces minimal overhead in communication
- MQTT is designed for narrowband communication channel and constrained devices
What is still unclear to me and under investigation is what is the most feasible way of providing security in communication, and how does MQTT cope with firewalls. Once these questions are clear to me, I'm ready to favor MQTT over WebSocket in embedded connectivity.
Actually you can have the best of both worlds with MQTT over Websockets. This is awesome for bringing MQTT to the browser and MQTT over TCP to devices. To learn more about that, look at this blog post: http://www.hivemq.com/mqtt-over-websockets-with-hivemq/
ReplyDeleteRegarding secure communication: You absolutely should use TLS with MQTT in order to get a secure and encrypted communication. You can even use client cert authentication. Of course this will add additional overhead to the communication.
Firewalls aren't typically a problem with MQTT, because the MQTT clients stay connected with a durable TCP connection once they connect, so you just have to make sure they can connect to the MQTT broker. So the broker doesn't have to "contact" the client directly.