Which IoT protocol wins the race?
Why HTTP is not suitable for IoT applications:
Memory and processing and power consuming: complex headers with a minimum of nine TCP packets.
No QoS support
But then, how should the ideal IoT application protocol look like?
Runs on constrained devices (little memory, battery powered)
Quality of Service (QoS), not just "fire-and-forget"
Send data to multiple devices with one transmit cycle
Standardized, widely supported (open source)
Asynchronous communication
Security support (encryption)
Run on IP (IPv6)
These points given, we pretty sure ending up with the following protocols on our list:
Constrained Application Protocol (CoAP)
Message Queue Telemetry Transport (MQTT)
MQTT for Sensor Networks (MQTT-SN)
Constrained devices
CoAP runs on UDP. MQTT requires TCP. MQTT-SN is transport layer agnostic (meaning it could run on UDP, TCP or any other transport protocol like UART).
As TCP is quite processing power and memory consuming, UDP (CoAP, MQTT-SN) is better suited for constrained devices (less overhead, faster wake-up and transmit). Moreover, CoAP was specially designed for microcontrollers as small as 8-bit (RFC 7252).
QoS
Quality of Service (QoS) means that you do not just fire-and-forget your messages (e.g. sensor data). So it really matters for machine-to-machine (M2M) communication as you want to make sure that certain messages do not get lost all the way through the internet.
MQTT and MQTT-SN support three QoS:
QoS 0: At most once (fire-and-forget). No guarantee of message arraival.
QoS 1: At least once. Message is guaranteed to arrive at least once at the recipient.
QoS 2: Exactly once. Message is guaranteed to arrive exactly once at the recipient.
Whereas CoAP only supports two QoS:
Non-confirmable messages (fire-and-forget)
Confirmable messages (comparable to MQTT QoS 1)
Send one single message to multiple devices
MQTT uses the publish-subscribe principle: a subscriber can subscribe to a certain topic and everytime this topic changes, the subscriber is updated.
CoAP is in the first place a one-to-one protocol. There is no publish-subscribe principle like in MQTT (which supports kind of a event based communication, CoAP is more state based). However, CoAP support multicast e.g. for resources discovery or server instructions to all.
Standardized and open source
MQTT was originally developed by IBM (1999). Today, it is standardized by Organization for the Advancement of Structured Information Standards (OASIS) and open source. MQTT-SN specification is open to everybody but behind MQTT-SN is not a organization for standardization (e.g. IETF or similar). Nonetheless, MQTT-SN will be part of Eclipse Paho release this June 2017.
CoAP was specified and standardized by the Internet Engineering Task Force (IETF). See RFC 7252.
Asynchronous
When a device sends a synchronous message, it waits and expects a response within a specified time period and is blocked in the meanwhile. As some devices in IoT applications are asleep for the most of the time, a synchronous communication does not make sense. Therefore, asynchronous communication is a must.
There are synchronous and asynchronous MQTT clients implementations available. Here an example of an asynchronous MQTT-SN gateway implementation.
CoAP does natively support asynchronous message exchanges. Furthermore, CoAP does support a GET with an observe option. This means if you for example want to observe a state of a light bulb, you will always get a message when the state of the light bulb changes (from ON to OFF). The observer can subscribe to any change in the state of an observable device.
Security
The IoT will never take off without security considerations. MQTT messages can be encrypted by TCP/TLS and CoAP by UDP/DTLS. As MQTT-SN runs on different networks, encryption depends on chosen network technology.
A MQTT broker may require username and password for authentication of clients which want to connect.
Summary
CoAP suites best for battery powered devices and the web-of-things (WoT), whereas MQTT has it's strength where reliable data transfer has highest priority and your device has enough power available.
Use MQTT-SN when you need MQTT in a battery powered device.
PLEASE leave a COMMENT or SHARE our article.
Thank you!