MQTT

An IoT solution comprises distributed sensors connected remotely over a network (local or the Internet) to a central processor which stores, analyses, and displays the data or takes action based on the data received from the sensors. An IoT solution relies on fast and reliable transmission of data and signals across all components, from sensors to gateways to processors to controllers to workers. A break or delay in this transmission could result in incorrect or ineffective outcomes.

Communication protocols like HTTP/HTTPS and data formats like XML used in web or mobile apps are not as well suited for IoT solutions since they require large amounts of metadata (in addition to the actual payload data) to be exchanged, which can overwhelm sensors that usually have low processing power and memory and need to use as less energy as possible.

To overcome this, a communication protocol known as MQTT is widely used in IoT solutions, along with the JSON data format.

IoT solutions also widely use an API architecture, invoking the services of gateways, processors and controllers as required.

When a program wants to send and receive data to and from another program, it can do it in two ways: one, send the data directly to the receiving program, and two, send the data to an intermediary program, which will then forward it to the receiving program.

In computing solutions, the first approach is referred to as a request-response architecture, while the second approach is referred to as a messaging architecture.

The messaging architecture uses an asynchronous communication mechanism. The sending program hands off some data (referred to as a message) to the intermediary program (referred to as the message broker) and continue its processing without awaiting a response from the message broker. The receiving program receives the message from the message broker whenever it is ready, which could be immediately or anytime later. The receiving program may send a response or acknowledgment to the sending program in the same asynchronous manner through the message broker.

A messaging architecture is an alternative to an API architecture when two programs want to exchange data. In an API architecture, the sending program directly calls the services of the receiving program. In a messaging architecture, the sending program hands off the data (referred to as a message in this context) to an intermediary program (which is known as the message broker). The message broker queues up the messages. The receiving program (the processor) connects to the message broker and picks up the data/messages from the queue and processes it. In the context of an IoT solution, the gateway can be designed to be a message broker.

There are two reasons why this architecture works well for IoT solutions. One, sensors often need to read data continuously in real-time and cannot afford to waste resources and time waiting for the receiver to accept data. And two, sensors do not need a response from the receiver, their job is to read and forward and move on.

The other advantage of a messaging architecture is that multiple receivers can pick up data/messages from the message broker queues for processing, unlike an API architecture where it is one sender to one receiver.

This architectural pattern is highly decoupled, minimising the mutual awareness that applications need to have of each other (in terms of technology, design, data formats, etc.) to be able to exchange messages.

It could be a confusing detail but important to understand that the communication between the sensors and processors and the message broker (or gateway) still uses API.

This architectural pattern minimizes the mutual awareness that applications need to have of each other (in terms of technology, design, data formats, etc.) to be able to exchange messages. This approach leads to a decoupled architecture. It is helpful and necessary when diverse applications need to communicate with each other.

This decoupling can have two dimensions: Space, where the sending and receiving programs do not need to know deployment or configuration details (i.e., server IP or port). They only need to know details about the broker and the time of sending and receiving programs, where it is not required to run parallelly. As you can imagine, asynchronous communication is considerably helpful in IoT solutions since sensor events may occur at random time intervals. The processor does not need to listen to an event frequently and may check with the message broker every once in a while using the application’s criticality frequency. Also, the sensor can relay the data to the message broker and continue to read more data without waiting for an acknowledgment where data will be processed as long as it knows the message broker will be continued to receive and will deliver it to the processor eventually.

MQTT (short for Message Queue Telemetry Transport) is the preferred standard protocol for messaging-based communication in an IoT solution. It is an extremely lightweight protocol compared to other messaging protocols used in traditional enterprise applications, and therefore it is ideal for connecting remote devices with low-powered processors, simple programming, and low network bandwidth. MQTT, a lightweight communication protocol specifically designed to tolerate intermittent connections, minimize the code footprint on devices and reduce network bandwidth requirements.

MQTT has the following characteristics that make it useful for IoT solutions:

• Lightweight and Efficient MQTT client applications are tiny and require minimal resources so they can be used on small microcontrollers. MQTT message headers are small to optimize network bandwidth.
• Reliable Message Delivery Reliability of message delivery is important for many IoT use cases. That is why MQTT has 3 defined quality of service levels: 0 - at most once, 1- at least once, 2 - exactly once
• Support for Unreliable Networks Many IoT devices connect over unreliable cellular networks. MQTT’s support for persistent sessions reduces the time to reconnect the client with the broker.
• Security Enabled MQTT makes it easy to encrypt messages using TLS and authenticate clients using modern authentication protocols, such as OAuth.

Several message broker solutions implement this protocol. You can install them on your local machines, or in some cases, use them directly on the cloud without requiring any local installation.