MQTT The Lightweight IoT protocol

When working with a network of many devices that need to send and receive data simultaneously we may encounter issues with connectivity. We often face issues with latency and wireless connections are often unreliable. We may also need to watch the bandwidth consumption especially for metered networks.

A quick solution to this problem is to use HTTP requests and build a publish-subscribe model to exchange data between different devices. There is a protocol that has been specifically designed to be lighter than the HTTP 1.1 protocol and works better in unreliable networks and intermittent connectivity. The Message Queuing Telemetry Transport (MQTT) Protocol is customized for this scenario in which multiple devices have to exchange data in near real time via the Internet while consuming the least possible network bandwidth.

The MQTT protocol is a Machine-to-Machine (M2M) and IoT connectivity protocol. It is a lightweight messaging protocol that works with a broker-based publish-subscribe mechanism and runs on top of Transmission Control Protocol / Internet Protocol (TCP/IP). MQTT is lighter than the HTTP 1.1 protocol, and hence it is a very interesting option when sending and receiving data in near real time with a publish-subscribe model and the lowest possible footprint is required. It is very popular in IoT, M2M, and embedded projects.

Advantages of MQTT

This protocol was designed to be suitable to support the following typical challenges in IoT, M2M, embedded, and mobile applications:

• Be lightweight to make it possible to transmit high volumes of data with small overheads
• Distribute minimal packets of data in huge volumes
• Support an event-oriented paradigm with asynchronous bidirectional low latency push delivery of messages
• Easily emit data from one client to many clients
• Make it possible to listen for events whenever they happen (event-oriented architecture)
• Support always-connected and sometimes-connected models
• Publish information over unreliable networks and provide reliable deliveries over fragile connections
• Work very well with battery-powered devices or require low power consumption Provide responsiveness to make it possible to achieve near real-time delivery of information
• Offer security and privacy for all the data
• Be able to provide the necessary scalability to distribute data to hundreds of thousands of clients

Understanding the Publish-subscribe pattern

In the publish-subscribe pattern, a client that publishes a message is decoupled from the other client or clients that receive the message. The clients don’t know about the existence of the other clients. A client can publish messages of a specific type and only the clients that are interested in specific types of messages will receive the published messages.

The publish-subscribe pattern requires a broker, also known as server. All the clients establish a connection with the broker. A client who sends a message through the broker is known as the publisher. The broker filters the incoming messages and distributes them to the clients that are interested in the type of received messages. Clients who register to the broker as interested in specific types of messages are known as subscribers. Hence, both publishers and subscribers establish a connection with the broker. Below is a diagram describing the protocol.

Note: The data for a message is known as payload. A message includes the topic to which it belongs and the payload.

Publishers and subscribers are decoupled in space because they don’t know each other. Publishers and subscribers don’t have to run at the same time. The publisher can publish a message and the subscriber can receive it later. Also note that the publish operation isn’t synchronized with the receive operation. A publisher requests the broker to publish a message and the different clients that have subscribed to the appropriate topic can receive the message at different times.

Asynchronous operation occurs when the publisher wants to avoid being blocked until the clients receive the messages. In synchronous operation with the broker, the publisher will continue the execution only after the operation was successful. That is, no other message will be sent if the previous one was not delivered. In most cases, you will want to take advantage of asynchronous operations.

A publisher that requires sending a message to hundreds/thousands of clients can do it with a single publish operation to a broker. It is the broker’s responsibility to send the published message to all the clients that have subscribed to the given topic. Since the publisher and subscriber are disconnected, the only way to know if a message was delivered to a subscriber is to make the subscriber a publisher so that it can publish to the broker that it has received a message.

QOS:

It stands for Quality of Service. There are basically three types.

QoS — 0: This does not guarantee if a message has been delivered successfully. It is like “fire and forget” type.

QoS — 1: This guarantees the message will be delivered at least once. But can be sent more than once.

QoS — 2: This guarantees that the message is sent only once.

The higher the QoS, the higher it consumes bandwidth to process the transmission.

Use cases for MQTT

MQTT was best designed for the following applications where data exchange is essential. Some of these include:

• Asset tracking and management
• Automotive telematics
• Chemical detection
• Environment and traffic monitoring
• Field force automation
• Fire and gas testing
• Home automation
• In-Vehicle Infotainment (IVI)
• Medical Messaging
• Point of Sale (POS) kiosks
• Railway
• Radio-Frequency Identification (RFID)
• Supervisory Control and Data Acquisition (SCADA)
• Slot machines