MQTT (Message Queuing Telemetry Transport or MQ Telemetry Transport) is a lightweight messaging protocol that provides resource-constrained network clients with an easy way to distribute telemetry information.
The MQTT protocol, which uses a subscribe/publish communication pattern, is used for M2M (machine-to-machine) communication and also 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 the connection through a subscribing client to a server (or broker) is broken or interrupted, the broker will buffer messages and transfer 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 by using either a custom or standard port defined by the broker’s operators.
When creating a connection, we must know that the server might continue an old session if it is provided with 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, it is usual for brokers to 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 referred to as a lightweight protocol 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.
Also, it consists of a message payload that is limited to 256 MB(Megabyte) of information and a QoS (Quality of Service) level.
During the communication phase, the client can perform operations such as 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 (+).
With the use of special wildcard characters, a client can subscribe 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 then terminates the connection.
This is called a graceful shutdown because it allows the client to reconnect by providing its identity and then resuming it easily.
If the disconnect happens suddenly without time, a publisher can send a DISCONNECT message.
Then the broker might send the subscribers a message from the publisher that the broker has previously cached (data stored in a reserved storage location for later use).
The message called a testament and last will, provides subscribers with instructions for 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 given 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 subscribe to 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. On the other hand, STOMP 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 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.
- Advanced Message Queuing Protocol (AMQP), just like MQTT, also 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 that is used 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 when compared to other 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 really 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 in open architectures where different applications from different manufacturers are expected to work seamlessly with each other.
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 very difficult because the complexity also 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 out-of-band, proprietary means.
