Message Queue Telemetry Transport (MQTT)
MQTT is the standard messaging and data exchange protocol for the Internet of Things (IoT). The MQTT protocol provides a scalable and cost-efficient way to connect devices over the Internet. We can use MQTT to deliver data over the Internet in near real-time with predefined guarantees of delivery. Connecting millions of IoT devices to our business infrastructure, sending instant updates, and moving data efficiently is where MQTT truly excels.
It is a lightweight messaging protocol that provides resource-constrained network clients with a simple way to distribute telemetry information. The protocol uses a publish/subscribe communication scheme that runs over TCP, supporting event-driven message exchange through wireless networks.
The MQTT protocol surrounds two subjects: a client and a broker. An MQTT broker is a server, while the clients are the connected devices. When a device -- or client -- wants to send data to a server -- or broker-- it is called a publish. When the operation is reversed, it is called a subscribe.
If the connection from a subscribing client to a broker is broken, then the broker will buffer messages and push them out to the subscriber when it is back online. If the connection from the publishing client to the broker is disconnected without notice, then the broker can close the connection and send subscribers a cached message with instructions from the publisher.
How MQTT Works
An MQTT session is divided into four stages:
connection
authentication
communication
termination
A client starts by creating a Transmission Control Protocol/Internet Protocol (TCP/IP) connection to the broker by using either a standard port or a custom port defined by the broker's operators. When creating the connection, it is important to recognize that the server might continue an old session if it is provided with a reused client identity.
The standard ports are 1883 for non-encrypted communication and 8883 for encrypted communication – using SSL/TLS. During the SSL/TLS handshake, the client validates the server certificate and authenticates the server. The client may also provide a client certificate to the broker during the handshake. The broker can use this to authenticate the client. While not specifically part of the MQTT specification, it has become customary for brokers to support client authentication with SSL/TLS client-side certificates.
Because the MQTT protocol aims to be a protocol for resource-constrained and IoT devices, SSL/TLS might not always be an option and, in some cases, might not be desired. On such occasions, authentication is presented as a cleartext username and password, which are sent by the client to the server -- this, as part of the CONNECT/CONNACK packet sequence. In addition, some brokers, especially open brokers published on the internet, will accept anonymous clients. In such cases, the username and password are simply left blank.
MQTT is called a lightweight protocol because all its messages have a small code footprint. Each message consists of:
1. a fixed header of 2 bytes
2. an optional variable header
3. a message payload limited to 256 megabytes of information
4. quality of service (QoS) level (0, 1, 2)
During the communication phase, a client can perform publish, subscribe, unsubscribe, and ping operations. The publish operation sends a binary block of data -- the content -- to a topic that is defined by the publisher.
MQTT supports message binary large objects (BLOBs) up to 256 MB in size. The format of the content will be application-specific.
Topic strings form a natural topic tree with the use of a special delimiter character, the forward-slash (/). A client can subscribe to -- and unsubscribe from -- entire branches in the topic tree with the use of special wild-card characters.
There are two types of wildcard characters:
a single-level wild-card character, the plus character (+)
a multilevel wild-card character, the hash character (#).
When a publisher or subscriber wants to terminate an MQTT session, it sends a DISCONNECT message to the broker and then closes the connection. This is called a graceful shutdown because it gives the client the ability to easily reconnect by providing its client identity and resuming where it left off.
Should the disconnect happen suddenly without time for a publisher to send a DISCONNECT message, the broker may send subscribers a message from the publisher that the broker has previously cached. The message, which is called a last will and testament, provides subscribers with instructions for what to do if the publisher dies unexpectedly.
Some popular MQTT Brokers are:
HiveMQ
Mosquitto
CloudMQTT
Adafruit IO
Last updated
