MQTT (Message Queuing Telemetry Transport or MQ Telemetry Transport) is a lightweight messaging protocol that allows resource-constrained network clients to easily distribute telemetry information.
The MQTT protocol uses a subscribe/publish communication pattern for M2M (machine-to-machine) communication and plays a crucial role in the IoT (Internet of Things).
The MQTT protocol is an excellent choice for wireless networks experiencing varying latency levels due to unreliable connections or occasional bandwidth constraints.
The MQTT protocol involves two subjects: the client and the broker.
MQTT broker is the server, while the clients are linked devices. When a client (or a device) wants to send data to a server (or broker), it is called a publish. When the operation is then reversed, it is called subscribing.
If a subscribing client’s connection to a server (or broker) is broken or interrupted, the broker buffers messages and transfers them to the subscriber when it is back online.
However, suppose the connection from a publishing client to the broker is disconnected or broken without notice.
In that case, the broker can end the connection and send subscribers a cached message with instructions from the publisher.
How Does MQTT Work?
An MQTT (MQ Telemetry Transport) session is divided into four stages:
- Connection
- Communication
- Authentication
- Termination
A client starts by creating a TCP/IP (Transmission Control Protocol/Internet Protocol) connection to the broker using a custom or standard port defined by the broker’s operators.
When creating a connection, we must remember that the server might continue an old session if we provide a reused client identity.
The standard ports are 8883 for encrypted communication and 1883 for non-encrypted communication using Transport Layer Security (TLS)/Secure Sockets Layer (SSL).
During the TLS/SSL handshake, the client checks the server certificate’s validity and approves the server.
The client can also provide a client certificate to the broker during the handshake.
The broker can use this to validate the client. While not specifically part of the MQTT specification, brokers usually support client authentication with TLS/SSL client-side certificates.
Because the MQTT protocol intends to be a protocol for IoT devices and resource-constrained, TLS/SSL might not always be an option and, in some cases, might not be desired.
In such incidents, authentication is presented as a cleartext password and username sent by the client to the server (as part of the CONNACK/CONNECT packet sequence).
Furthermore, some brokers, mostly open brokers published online, will accept unknown clients. In such cases, the password and username are left blank.
MQTT is lightweight because all its messages have a small code footprint.
Each message of MQTT consists of a fixed header (2 bytes) and an optional variable header.
It also consists of a message payload limited to 256 MB(Megabyte) of information and a QoS (Quality of Service) level.
During the communication phase, the client can perform subscribe, publish, ping, and unsubscribe operations.
The publish operation sends the content (a binary data block) to a topic the publisher defines.
MQTT (MQ Telemetry Transport) supports message BLOBs (binary large objects) up to 256 MB(Megabyte) in size. Also, the format of the content will be application-specific.
Topic subscriptions are made using a SUBACK/SUBSCRIBE packet pair, and unsubscribing is likewise performed using a UNSUBACK/UNSUBSCRIBE packet pair.
Topic strings form a natural topic tree using the forward-slash (/) character (a special delimiter character).
There are two wildcard characters: a multilevel wildcard character, the hash character (#); and a single-level wildcard character, the plus character (+).
Using special wildcard characters, a client can subscribe to and unsubscribe from all the branches in the topic tree.
The special topic character, the dollar character ($), excludes a topic from any root wildcard subscriptions.
Normally, $ is used to transport the system or server-specific messages.
Another operation a client can perform during the communication phase is to ping the broker server using a PINGRESP/PINGREQ packet sequence.
This packet sequence harshly translates to YES I AM ALIVE/ARE YOU ALIVE.
Also, the ping operation has no other function than maintaining a live connection and ensuring a router or gateway has not shut down the TCP(Transmission Control Protocol) connection.
When a subscriber or publisher wants to end an MQTT session, it sends a DISCONNECT message to the broker and terminates the connection.
This is called a graceful shutdown because it allows the client to reconnect by providing its identity and resuming it easily.
If the disconnect happens suddenly without time, a publisher can send a DISCONNECT message.
The broker might then send the subscribers a message from the publisher stating that the broker has previously cached data (data stored in a reserved storage location for later use).
The message called a testament and last will, provides subscribers with instructions on what to do if the publisher suddenly dies.
MQTT in IoT (Internet of Things)
MQ Telemetry Transport is a commonly used IoT (Internet of Things) protocol.
It enables resource-constrained IoT devices to publish or send information about a topic to a server that functions as an MQTT message broker.
In this case, the broker then pushes the information out to those formerly subscribed to the topic. To a human being, a topic looks like a hierarchical file path.
Clients can use a wildcard character to subscribe to multiple levels or a specific topic’s hierarchy level.
For example, EVRYTHNG, ThingWorx, and Carriots IoT platforms support the MQTT protocol.
Competing protocols
Several transfer protocols compete with MQ Telemetry Transport. These transfer protocols include the following:
- Streaming/Simple Text Oriented Messaging Protocol (STOMP) is text-based. It does not deal with topics and queues; it uses a send semantic with a destination string.
- Data Distribution Service (DDS) for real-time systems is a middleware protocol and API standard that can directly subscribe to or publish communications in real time in embedded systems.
- Constrained Application Protocol (CoAP) is a specialized web transfer protocol well suited for IoT(Internet of Things). CoAP also uses a response/request communication pattern.
- Like MQTT, Advanced Message Queuing Protocol (AMQP) uses a subscribe/publish communication pattern.
- Mosquitto is an open-source MQTT broker.
- SSI (Simple Sensor Interface) is a communications protocol for data transfer between a combination of sensors and computers
- Simple Media Control Protocol (SMCP) is a CoAP stack in embedded environments. SMCP is also C-based
Pros and Cons of MQTT
Message Queuing Telemetry Transport (MQTT) has a few clear advantages and disadvantages compared to competing protocols.
Pros
- Efficient and fast message delivery
- MQTT uses a low network usage due to minimized data packets
- MQTT has efficient data transmission and is also quick to implement due to its being a lightweight protocol
- One major advantage of MQTT is the reduction of network bandwidth
- MQTT uses a small amount of power, which is good for connected devices
- Efficient distribution of data
- Successful implementation of remote control and sensing
Cons
- It is unencrypted. Instead, MQTT uses SSL/TLS/ for security encryption
- MQTT’s resource discovery works on a flexible topic subscription, whereas CoAP(Constrained Application Protocol) uses a reliable resource discovery system
- Creating a globally scalable MQTT network is complex
- MQTT’s transmit cycles are slow when compared to CoAP
MQTT Challenges: Interoperability, Security, and Authentication
One of the drawbacks that MQTT is facing is its lack of interoperability. Problems can occur because message payloads are binary, and it has no information as to how they are encoded.
This applies most to open architectures, where applications from different manufacturers are expected to work seamlessly together.
Another challenge of MQTT is security. When the MQTT protocol was designed, security wasn’t addressed well, and the protocol is usually used in secure back-end networks for specific purposes in an application.
Creating a globally scalable MQTT network is difficult because the complexity increases as the topic size becomes big.
For instance, let’s represent the topic structure as a huge tree; though it can be easily formed, there is no clear way to divide it into smaller logical domains that can be federated.
Also, MQTT has very few authentication features built into the protocol. Passwords and usernames are sent in cleartext, and any form of secure use of MQTT must use TLS/SSL, which is not a lightweight protocol.
In addition, It is a hard process to authenticate clients with client-side certificates.
Also, there is no way to control who owns a topic and who can publish information on it in MQTT except by using proprietary, out-of-band means.
