Message Queuing Telemetry Transport (MQTT) is a lightweight, simple, and open-source messaging protocol. It is the most widely used protocol for communication in the Internet of Things (IoT) or machine-to-machine (M2M) environments. The main goal of MQTT is to facilitate messaging and data exchange between IoT and Industrial IoT (IIoT) devices, such as sensors, that have limited bandwidth. IoT/IIoT devices using the MQTT protocol operate on a publish-subscribe model, where a device (client) can publish messages or data to specific topics while also subscribing to receive data from other devices. It functions over TCP/IP.
The MQTT operates on a publish-subscribe model, allowing devices/clients to communicate. However, communication between clients doesn’t occur directly; instead, it is facilitated by an MQTT broker. The broker acts as a middleware, receiving and distributing data between clients. This publish-subscribe model revolves around two key roles: publisher and subscriber
Clients can act as both publishers and subscribers simultaneously. In MQTT, the exchange of messages is organized by topics (MQTT Topics), which function like channels. When a publisher wants to send a message, it publishes the message to a specific topic, such as sensor/temperature. Devices interested in that topic will subscribe to it and receive the data efficiently. This entire process is managed by the broker, which takes data from the publisher client and forwards it to the clients that have subscribed to that particular topic.
In case of network issues or unexpected connection failures, the publisher client can send a "Last Will Message," a cached message containing instructions for the subscribing clients. If there is a disconnection between the broker and the subscriber, the broker stores the messages and delivers them to the subscriber once the connection is reestablished.
MQ Telemetry Transport (MQTT) defines several message types that facilitate communication between MQTT clients and the MQTT broker in IoT systems. Each type serves a unique role in the communication process. Among the various MQTT message types, the following four are crucial:
1. CONNECT – The CONNECT message is sent by a client to initiate a connection with the MQTT broker. This message helps the broker identify the client and establish the connection. The CONNECT message includes details such as the client’s ID, connection options, and login credentials.
2. DISCONNECT – The DISCONNECT message is used by a client to close its connection with the MQTT broker. By sending this message, the client informs the broker that it no longer wishes to communicate. This ensures that the broker is aware that the client is going offline properly, rather than experiencing an unexpected disconnection.
3. PUBLISH – The PUBLISH message is used to send data to a specific topic. It contains the payload, which is the actual data, along with metadata such as the topic name, Quality of Service (QoS) levels, and whether the message should be retained by the broker. The PUBLISH message allows data to move from a client to the broker, where it can then be distributed to other clients subscribed to that topic.
4. SUBSCRIBE – The SUBSCRIBE message is sent when a client or device wants to receive data on a specific topic published by another client. By subscribing, the client tells the broker which topic it is interested in. Once subscribed, the client will start receiving all messages published to that topic. This is how devices notify the broker that they want to receive specific types of data.
Check out the table below for more MQTT message types and descriptions!
It is suitable for M2M communication as it decreases the need for network bandwidth. Also, it accommodates unstable networks and requires less development effort. The protocol serves to exchange data between controlled devices and server applications. A system that uses the Internet of Things (IoT) is a collection of interconnected objects that can communicate with one another.For this concept, Message Queuing Telemetry Transport works well. Some justifications are as follows:
Some benefits of MQTT are as follows :
Term to address that allows
clients to share information.
Representing an ongoing
connection between a
client
and a broker
Storing the “Last Good
Message” on a
topic
Checking the status of the TCP/IP connection
Allows you to receive data directly into a web browser
MQTT stands for Message Queuing Telemetry Transport. It's a light-weight, simple messaging protocol that helps the smart devices (devices which are inter-connected over internet) to communicate seamlessly by sending and receiving data, especially in situations where the network or power resources are limited
MQTT is the most widely used protocol in IoT. It's because of its ability to provide a reliable way for devices to communicate even in environments with low bandwidth or unstable conditions. Its publish/subscribe model permits the devices to send data only when it is necessary, thus making it efficient for large network of connected devices in smart homes, factories, and so on.
Following are some practical use cases of the MQTT:
MQTT is an application layer protocol built on top of the TCP protocol for data transmission, ensuring reliable and ordered delivery of messages. TCP (Transmission Control Protocol) provides a stable connection between devices, making it ideal for applications where data integrity is vital. There is a variant called MQTT-SN (MQTT for Sensor Networks) that is designed exclusively for edge sensor networks, is built over UDP (User Datagram Protocol)
MQTT is easy of use and is essential for situations where response time, throughput, lower battery, and bandwidth usage are crucial. Compared to other IoT communication protocols like HTTP and CoAP, MQTT is better because of its light-weight design which allows for faster and more efficient data transmission. Also, its publish/subscribe model simplifies communication between devices, thus reducing the need for constant connections. All these makes MQTT a better communication protocol than other protocols.
Yes, MQTT is designed to support very secure communication. MQTT supports authentication methods to ensure that only authorized devices can connect and exchange information. Additionally, it also offers various security measures like encryption through SSL/TLS, which protects data as it travels between devices. Thus, these features makes Message Queuing Telemetry Transport protocol a safe choice for transmitting sensitive data in IoT applications.
Yes, MQTT is an open-source protocol that is standardized by organizations like OASIS and ISO. This means it is available for anyone to use, implement, or modify without any restrictions. As it is not owned by any specific company, MQTT can be adopted widely across various platforms and applications
No, MQTT is not RESTful. While both MQTT and REST are used for communication between devices, they have
different architecture and different purposes to serve.
MQTT relies on publish/subscribe model that allows devices to send and receive messages/data in
real-time.
On the other hand, REST relies on request/response model that allows clients to request data from the
server.
To know more, read our
MQTT vs REST blog!
1883 is the standard port of MQTT. This is the default port which is used for non-secure connections, allowing devices to communicate with each other easily. When TLS is enabled for secure connection, MQTT generally uses the port 8883 as an added layer of security for data transmission
Yes, Of course. You need a broker to use MQTT. It is the broker that acts as a central hub that manages all communication between the devices (clients). The role of the MQTT broker is to get the messages/data from the devices that acts as a publisher and distribute those messages to the devices that acts as subscriber. Without the broker, the MQTT system wouldn't be able to route or manage messages efficiently
MQTT is highly suitable for IIoT applications due to the following features:
These factors make it the preferred messaging protocol for industrial applications requiring reliable and efficient data exchange.
Yes, MQTT supports QoS, which helps ensure reliable message delivery. QoS allows the sender to specify how reliably messages should be delivered, offering options to suit different communication needs. This feature makes MQTT flexible for various IoT applications, from non-critical data to time-sensitive information
MQTT QoS comprise of 3 levels which got classified as per increasing order of overhead
QoS 0 – At most once
QoS 1 – At least once
QoS 2 – Exactly once
To know more about QoS, navigate to MQTT QoS article
An MQTT topic is a string or pattern that defines the destination or subject of a message. It serves to categorize and route messages within the publish-subscribe model, allowing devices to subscribe to specific topics of interest. Topics can have a hierarchical structure, using slashes (/) to separate different levels, which enables organized and efficient message filtering. This system allows multiple devices to receive relevant messages without unnecessary data traffic, making communication more effective.
Retained messages are a feature in MQTT that allows a message published to a topic to get stored by the broker. This means that when a new subscriber connects to that topic, they immediately receive the last retained message, ensuring they have the most recent data without having to wait for new updates. This feature is especially useful for providing critical information, like device status or configuration settings, to new subscribers right away.
The maximum message size in MQTT is defined by the broker and can vary, but it is generally up to 256 MB. However, it's recommended to keep messages small to optimize performance and reduce latency, especially in constrained environments
MQTT ensures message ordering by delivering messages in the order they are published when using QoS 1 or QoS 2. This means that subscribers will receive messages in the same sequence they were sent, which is crucial for applications where the order of data is important
The Last Will and Testament (LWT) feature allows a client to specify a message that will be sent by the broker if the client unexpectedly disconnects. This feature is useful for notifying other devices about the client's status, helping to maintain awareness in the network
Yes, MQTT is well-suited for mobile networks due to its lightweight nature and low bandwidth consumption. This makes it ideal for applications where devices may have intermittent connectivity, such as mobile sensors or IoT devices that rely on cellular networks
Yes, MQTT is highly suitable for real-time applications because of its low latency and efficient message delivery. The publish/subscribe model allows for instant notifications, making it ideal for use cases such as live data feeds, remote monitoring, and instant messaging