What is MQTT and Why MQTT is IDEAL for IoT

MQTT (Message Queue Telemetry Transmission) is an IoT Communication protocol built on the TCP/IP protocol of the Internet. There is no doubt that MQTT protocol has become a standard for IoT communications because it really has a lot of advantages.

This article will let you have a basic understanding of MQTT and will have a comparison between other internet protocols and MQTT. After reading this article, you will know why MQTT is IDEAL for IoT applications.

What is MQTT？

MQTT was originally invented and developed by IBM in the late 1990s. Its original purpose was to link sensors on oil pipelines with satellites.

As the name suggests, it is a messaging protocol that supports asynchronous communication between parties. The asynchronous message protocol separates the message sender from the receiver in space and time, so it can be expanded in an unreliable network environment.

Although it is called message queue telemetry transmission, it has nothing to do with message queue, but uses a publish and subscribe model.

At the end of 2014, it officially became an OASIS open standard and was supported in some popular programming languages (through the use of multiple open-source implementations).

In order to understand why MQTT is so suitable for IoT developers, we first analyze why other popular network protocols have not been successfully applied in IoT.

Why not choosing HTTP?

Most developers are already familiar with HTTP Web services. So why not let IoT devices connect to web services? The device can send its data in the form of HTTP requests and receive updates from the system in the form of HTTP responses.

This request and response model has some serious limitations:

1. HTTP is a synchronization protocol. The client needs to wait for the server to respond. Web browsers have such requirements but at the expense of scalability.

2. HTTP is unidirectional. The client must initiate a connection. In IoT applications, devices or sensors are usually clients, which means they cannot passively receive commands from the network.

3. HTTP is a 1-1 protocol. The client sends a request and the server responds. Sending messages to all devices on the network is not only difficult but also costly, and this is a common use case in IoT applications.

4. HTTP is a heavyweight protocol with many headers and rules. It is not suitable for restricted networks.

The two processes of the HTTP protocol

The two processes of the HTTP protocol, Request, and Response, both have their own language formats. Let’s see what they are.

Request message format:

<method> <request-URL> <version>

<headers>

<entity-body>

Response message format:

<version> <status> <reason-phrase>

<headers>

<entity-body>

Here are two examples:

Request message:

GET /index.html HTTP/1.1

Accept: text/*

Host: www.myweb.com

Response message:

HTTP/1.1 200 OK

Content-type: text/plain

Content-length: 3 

For these reasons, most high-performance, scalable systems use asynchronous message buses for internal data exchange instead of Web services.

Other Protocols

In fact, the most popular message protocol used in enterprise middleware systems is called AMQP (Advanced Message Queuing Protocol).

However, in high-performance environments, computing power and network latency are usually not a problem.

AMQP is committed to achieving reliability and interoperability in enterprise applications. It has a huge feature set, but it is not suitable for resource-constrained IoT applications.

In addition to AMQP, there are other popular messaging protocols.

For example, XMPP (Extensible Messaging and Presence Protocol, Extensible Messaging and Presence Protocol) is a peer-to-peer instant messaging (IM) protocol.

It is highly dependent on features that support IM use cases, such as presence status and media connection. Compared with MQTT, it requires much more resources on devices and networks.

The advantages of MQTT.

MQTT is a lightweight and flexible network protocol dedicated to achieving the proper balance for IoT developers:

• This lightweight protocol can be implemented on severely restricted device hardware and high latency/ bandwidth-limited networks.

• Its flexibility makes it possible to provide support for diverse application scenarios of IoT devices and services.

Why is MQTT so lightweight and flexible?

A key feature of the MQTT protocol is the publish and subscribe model. As with all messaging protocols, it separates the publisher of the data from the consumer.

It has the following main features:

1. Use the publish/subscribe message model to provide one-to-many message publishing and decoupling between applications;

2. Message transmission does not need to know the load content;

3. Use TCP / IP to provide network connection;

4. There are three types of service quality for news release:

• QoS 0: “At most once”, the message release completely depends on the underlying TCP / IP network. The distributed message may be lost or duplicated. For example, this level can be used for environmental sensor data, a single data loss is okay, because there will be a second transmission soon.

• QoS 1: “At least once” to ensure that the message can arrive, but the message may be repeated.

• QoS 2: “Only once” to ensure that the message only arrives once. For example, this level can be used in a billing system, where repeated or missing messages can lead to incorrect charging.

5. Small transmission, the overhead is very small (fixed-length header is 2 bytes), protocol exchange is minimized to reduce network traffic;

6. Use the Last Will and Testament features to notify the relevant parties of the abnormal interruption mechanism of the client;

In the MQTT protocol, an MQTT data packet is composed of three parts:

• a fixed header (Fixed header)
• a variable header (Variable header)
• a message body (payload).

The transmission format of MQTT is very small, the smallest data packet is only 2 bits, and there is no application message header.

More explanation about the Publish/Subscribe Model

The MQTT protocol defines two types of entities in the network: a message broker and some clients. The agent is a server that receives all messages from the client and then routes these messages to the relevant target client.

The client is anything that can interact with the agent to send and receive messages. The client can be an on-site IoT sensor or an application that processes IoT data in a data center.

• The client connects to the agent. It can subscribe to any message “topic” in the agent. This connection can be a simple TCP / IP connection or an encrypted TLS connection used to send sensitive messages.

• The client publishes messages within a certain topic by sending the message and topic to the agent.

• The agent then forwards the message to all clients that subscribe to the topic.

Because MQTT messages are organized by subject, application developers have the flexibility to specify that certain clients can only interact with certain messages.

For example:

The sensor will publish readings within the “sensor_data” topic and subscribe to the “config_change” topic. Data processing applications that store sensor data in the back-end database subscribe to the “sensor_data” topic.

The management console application can receive commands from the system administrator to adjust the sensor configuration, such as sensitivity and sampling frequency, and post these changes to the “config_change” topic.

Summary

Above is a comparison chart between MQTT and HTTP, we believe after reading this article, you will have a basic understanding of MQTT and why it is ideal for IoT applications.

In the future, we will have some tutorials using our gateway product such as the ODYSSEY – X86J4105, the ODYSSEY – STM32MP157C, the Raspberry Pi, and Grove Sensors to teach you how to build IoT applications based on MQTT. How to use Eclipse Mosquitto to develop the MQTT applications.

Please stay tuned.

Also if you have anything you want to discuss, welcome to leave a comment to us.

About Author