Data Protocols Behind IoT
The Internet of Things covers many industries and has many implementations which are scaled from several constrained devices up to massive cross-platform deployments of embedded technologies and cloud systems connecting in real-time.
Home Automation often deals with constrained devices such as smartphones. There are two most suitable for small devices protocols: MQTT and CoAP.
MQTT and CoAP have much in common:
- Both are open standards
- Provide mechanisms for asynchronous communication
- Run on IP
MQTT overview
MQTT is lightweight messages oriented publish/subscribe protocol. There are several key definitions: client, broker and topic
- MQTT client is any device from a micro controller up to a full-fledged server, that has an MQTT library running and is connecting to an MQTT broker over any kind of network
- The broker is primarily responsible for receiving all messages, filtering them, decide who is interested in it and then sending the message to all subscribed clients.
- Messages are published to an address called topic. Clients subscribe to topics and “listen” to them receiving every message that’s published to a topic. Topics in MQTT have hierarchical structure. But there is an opportunity to use wildcards “+” and “#”. “+” refers to a single directory while “#” matches any number of them.
For instance, topic home/+/humidity matches home/kitchen/humidity but not home/kitchen/bar/humidity
home/# matches home/kitchen/bar/humidity
MQTT has several useful features like Last Will and Testament Message and Retained Messages. When a client disconnects unexpectedly, a broker send a message to all subscribed to a topic clients. Retained message updates newly connected clients with a status.
MQTT brokers may require username and password authentication from clients to connect. To ensure privacy, the TCP connection may be encrypted with SSL/TLS. There are also three levels of Quality of Services.
CoAP overview
CoAP is the Constrained Application Protocol. It is a document oriented protocol which is designed for constrained devices.
CoAP uses a client/server model where clients send requests to servers and servers respond to them. Clients may GET, PUT, POST and DELETE resources. Messages in CoAP can be “confirmable” or “nonconfirmable”.
In CoAP is available content negotiation. To express a preferred representation of a resource clients use Accept option, and servers respond with a Content-Type. This allow s client and server evolve independently from each other.
CoAP Protocol provides its users with the ability to observe a resource. It means that after transferring the initial document, a server may keep on replying. You just need to set the observe flag on a CoAP GET request. It allows clients to receive state changes if they occur.
Because CoAP is built on top of UDP not TCP, SSL/TLS are not available to provide security. DTLS, Datagram Transport Layer Security provides the same assurances as TLS but for transfers of data over UDP.
Сonclusion
MQTT is many-to-many communication protocol. It passes messages among many clients through a central broker. It’s perfect for live data. Whereas CoAP is one-to-one protocol for transferring state information between client and server.
In MQTT there is no opportunity to label messages with types or other metadata in order clients to understand it. Clients have to know message formats beforehand to communicate with each other. Conversely, CoAP has an option of content negotiation and discovery. Devices can probe each other to find ways of exchanging data.
Both protocols are significant and have their own pros and cons. Choosing the right protocol depends on your application.
