IoT Primer
The internet landscape is continuously evolving, and with the introduction of faster networks such as 5G, virtually everything will be connected. This capability of more rapid, low latency internet access will spur innovation and create previously unforeseen devices. Hence, the term IoT is often broached up when talking about the future of internet connectivity.
The Internet of Things — IoT, for short — is made up of devices that connect to the internet and share data with each other. Any device or object that is equipped with a Wi-Fi chip that connects to the internet and shares/receives information is an IoT device. For instance, voice-activated speakers, thermostats or motion-sensing Wi-FI routers. All of them are examples of IoT devices. While connecting to the internet is the only requirement, actual value comes from the communication to a back-end service that can perform computations, mutations, aggregations, and all that fancy jazz!
Limitations of IoT Communication over HTTP
Communication between the devices becomes a critical aspect of the IoT infrastructure. The underlying communication protocol needs to be fast, secure, reliable and scalable enough to support mass-produced devices and simultaneously provide value. Most developers are familiar with the HTTP protocol used in web services, so why not connect IoT devices with HTTP-supported web services and call it a day? Depending on the type of use case, you can, but it only works for a small subset of cases. There are several limitations when using HTTP with IoT infrastructure.
HTTP is one-way communication - All requests are initiated by the client, and the server responds with a response. IoT devices act as a client and hence can only create requests but cannot receive any commands passively to perform an action.
HTTP is a synchronous protocol - All web browsers wait for the server to respond to a particular request, whereas this may not be the case for IoT devices. For instance, a group of sensors posting data in a high latent/unreliable network, synchronous communication may be problematic or even detrimental where precision calculations are fundamental.
HTTP is intrinsically optimized for one-to-one communication - The client makes a request, and the server responds. When a collection of IoT devices are working together, it might make sense to broadcast a response to a group of devices which is inherently complicated to achieve with HTTP protocol.
HTTP is document-centric - HTTP is optimized to share documents, meaning message sizes are much larger and need to be parsed, evaluated, etc. Thus this creates bottlenecks for already resource-constrained devices such as sensors.
For the above reasons, HTTP can not provide a suitable ecosystem for several IoT use cases. Thus, an alternative that overcomes these obstacles is MQTT.
What is MQTT
MQTT stands for Message Queue Telemetry Transport is built on top TCP/IP stack, initially tailored towards facilitating communication between sensors and oil pipelines. It became an OASIS standard messaging protocol for IoT devices in 2014. However, its name has nothing to do with messaging queues and is actually based on Publish-Subscribe or pub-sub model. It has minimal overhead and is designed for reliable communication over unreliable connectivity.
Key Characteristics of MQTT
Binary Responses - MQTT is a binary-based protocol; the control element, unlike HTTP, is bytes. Text-based protocols are not suitable for machines as all machines operate via binary data manipulation. The smallest possible response over MQTT is 2 bytes, whereas the minimum possible response is 17 bytes over HTTP. Therefore, MQTT is lightweight and super-efficient.
Bi-Directional Communication - MQTT allows messaging between the device to cloud and cloud to the device. Thus, enabling message broadcasting.
Data Agnostic - The transport of payload itself is agnostic to the content of payload, hence it is possible to send a payload of all imaginable data types (even custom data types).
Built on top TCP/IP - This provides necessary benefits of using TCP such as packet reliability, persistence etc. Furthermore, MQTT can also run SSL/TLS, ensuring the data communication is encrypted and secure.
The above-listed benefits are vital in supporting IoT devices while providing necessary scalability. However, the actual benefits stem from the publish-subscribe architecture embodied by the MQTT protocol.
Publish-Subscribe Model
In a traditional server-client architecture, the client communicates to a server, and the server responds back with a response. In contrast to the conventional view, client-server entities are decoupled into two entities in the pub-sub model, broker and clients. There are two types of clients, a publisher, a client that sends messages and a subscriber, which receives messages.
The purpose of the broker, as the name suggests, is to facilitate message passing between the clients. All messaging in the MQTT broker is distributed based on topics. A subscriber client subscribes to particular topics, and similarly, a Publisher client publishes a message and topic to the broker. The broker then, based on the topic, forwards the messages to appropriate clients. This decoupling provides numerous benefits over traditional client-server architecture.
Each client does not need to know every other client's existence. To receive or publish messages, the client only needs to know the broker's host IP.
Each client does not need to run simultaneously. Brokers can store messages and enable the creation of new topics on the fly. Hence, clients go through their cycle of receiving and sending notifications.
Each client can work asynchronously to send and receive messages.
Figure 1: Pub-Sub in the smart speaker
Conclusion
This article provides a high-level overview of the MQTT protocol and contrasts it against the beloved HTTP. It only introduces MQTT at a surface but reasons about the benefits of using it over the widely popular HTTP. If you are interested in learning more about MQTT, check out the links attached below.
Top comments (1)
Like, Comment and Subscribe