MQTT

Overview

The MQTT protocol defines two types of network entities: a message broker and a number of clients. An MQTT broker is a server that receives messages from publishing clients and then routes the messages to the appropriate destination clients. An MQTT client is any device (from a microcontroller up to a full-fledged server) that runs an MQTT library and connects to an MQTT broker over a network.

Information is organized in a hierarchy of topics. When a publisher has a new item of data to distribute, it sends a control message with the data to the connected broker. The broker then distributes the information to any clients that have subscribed to that topic. The publisher does not need to have any data on the number or locations of subscribers; and subscribers, in turn, do not have to be configured with any data about the publishers.

If a broker receives a message on a topic for which there are no current subscribers, the broker discards the message unless the publisher of the message designated the message as a retained message. A retained message is a normal MQTT message with the retained flag set to true. The broker stores the last retained message and the corresponding quality of service (QoS) for the selected topic. Each client that subscribes to a topic pattern that matches the topic of the retained message receives the retained message immediately after they subscribe. The broker stores only one retained message per topic. This allows new subscribers to a topic to receive the most current value rather than waiting for the next update from a publisher.

When a publishing client first connects to the broker, it can set up a default message to be sent to subscribers if the broker detects that the publishing client has unexpectedly disconnected from the broker.

Clients only interact with a broker, but a system may contain several broker servers that exchange data based on their current subscribers' topics.

A minimal MQTT control message can be as little as two bytes of data. A control message can carry nearly 256 megabytes of data if needed. There are 14 defined message types used to connect and disconnect a client from a broker, to publish data, to acknowledge receipt of data, and to supervise the connection between client and server.

MQTT relies on the TCP protocol for data transmission. A variant, MQTT-SN, is used over other transports such as UDP or Bluetooth.

MQTT sends connection credentials in plain text format and does not include any measures for security or authentication. This can be provided by using TLS to encrypt and protect the transferred information against interception, modification or forgery.

The default unencrypted MQTT port is 1883. The encrypted port is 8883.

MQTT broker

The MQTT broker is a piece of software running on a computer (running on-premises or in the cloud), and could be self-built or hosted by a third party. It is available in both open source and proprietary implementations.

The broker acts as a post office. MQTT clients do not use a direct connection address of the intended recipient, but use the subject line called "Topic". Anyone who subscribes receives a copy of all messages for that topic. Multiple clients can subscribe to a topic from a single broker (one to many capability), and a single client can register subscriptions to topics with multiple brokers (many to one).

Each client can both produce and receive data by both publishing and subscribing, i.e. the devices can publish sensor data and still be able to receive the configuration information or control commands (MQTT is a bi-directional communication protocol). This helps in both sharing data, managing and controlling devices. A client cannot broadcast the same data to a range of topics, and must publish multiple messages to the broker, each with a single topic given.

With the MQTT broker architecture, the client devices and server application become decoupled. In this way, the clients are kept unaware of each other's information. MQTT, if configured to, can use TLS encryption with certificate, username and password protected connections. Optionally, the connection may require certification, in the form of a certificate file that a client provides and must match with the server's copy.

In case of failure, the broker software and clients can automatically hand over to a redundant/automatic backup broker. Backup brokers can also be set up to share the load of clients across multiple servers on site, in the cloud, or a combination of these.

The broker can support both standard MQTT and MQTT for compliant specifications such as Sparkplug. This can be done with the same server, at the same time and with the same levels of security.

The broker keeps track of all the session's information as the device goes on and off, in a function called "persistent sessions". In this state, a broker will store both connection info for each client, topics each client has subscribed to, and any messages for a topic with a QoS of 1 or 2.

The main advantages of an MQTT broker are:

1. Elimination of vulnerable and insecure client connections (when appropriately configured).
2. Ability to easily scale from a single device to thousands.
3. Management and tracking of client connection states, including security credentials and certificates (when appropriately configured).
4. Reduction of strain on cellular or satellite networks without compromising security (when appropriately configured).

Message types

Connect

Waits for a connection to be established with the server and creates a link between the nodes.

Disconnect

Waits for the MQTT client to finish any work it must do, and for the TCP/IP session to disconnect.

Publish

Returns immediately to the application thread after passing the request to the MQTT client.

Version 5.0

In 2019, OASIS released the official MQTT 5.0 standard. Version 5.0 includes the following major new features:

• Reason codes: Acknowledgements now support return codes, which provide a reason for a failure.
• Shared subscriptions: Allow the load to be balanced across clients, thus reducing the risk of load problems.
• Message expiry: Messages can include an expiry date and are deleted if they are not delivered within this time period.
• Topic alias: The name of a topic can be replaced with a single number.

Quality of service

Each connection to the broker can specify a QoS measure. These are classified in increasing order of overhead:

• At most once – the message is sent only once and the client and broker take no additional steps to acknowledge delivery (fire and forget).
• At least once – the message is re-tried by the sender multiple times until acknowledgement is received (acknowledged delivery).
• Exactly once – the sender and receiver engage in a two-level handshake to ensure only one copy of the message is received (assured delivery).

This field does not affect handling of the underlying TCP data transmissions; it is only used between MQTT senders and receivers.

Security

MQTT protocol version 3.1.1 requires the server (broker) to use a timeout that is one-and-a-half times the keepalive value specified by the client. This (and similar keepalive functionalities in other protocols such as HTTP) enables a slow DoS attack published in 2020 called SlowITe, in which the attacker tries to open and maintain as many connections as possible, depriving legitimate users of their connections. New variations of the attack and new detection/mitigation methods are topics of current research.

Clustering

The MQTT specification defines communication between a client and a single broker and does not specify communication between brokers. Deployments that need more capacity or availability than a single broker provides rely on implementation-specific mechanisms. The two common approaches are bridging, in which one broker connects to another broker as a client and forwards messages for selected topics, and clustering, in which a group of broker nodes shares subscription and session state and appears to clients as a single logical broker.

Eclipse Mosquitto implements bridging through broker configuration. Clustered brokers such as EMQX and HiveMQ run as multi-node systems whose nodes share client sessions, topic subscriptions, and routing information. A 2020 study that compared distributed deployments of three MQTT brokers on an edge-gateway cluster found substantial differences between implementations in throughput, latency, and message loss during node failure.

Limitations

Message ordering

MQTT does not guarantee that messages published by independent clients arrive at subscribers in the order they were generated. The OASIS MQTT specification provides ordering guarantees only within a single client session on a single topic; events originating from separate clients or generated across independent connections may be delivered out of sequence.

This limitation is particularly consequential in IoT deployments that use MQTT lifecycle events (connect and disconnect notifications) to track device connectivity state. Major broker implementations acknowledge this directly: Amazon Web Services states in its AWS IoT Core developer documentation that "lifecycle messages might be sent out of order" and that subscribers "might receive duplicate messages". Similarly, HiveMQ's engineering documentation notes that "strict ordering across publishing clients requires additional strategies such as dedicated routing and sequence numbers."

The practical consequence is that a disconnect notification generated before a reconnect notification may arrive at the subscribing application after it, causing monitoring systems that apply a last-write-wins policy to record a device as offline when it has already reconnected. This is a known failure mode in event-driven architectures and was characterised in the distributed systems literature as an inherent property of asynchronous message passing by Leslie Lamport in 1978. Independent benchmarks have documented the operational cost of event ordering inversions in production IoT deployments.

Commonly applied mitigations include debounce windows (delaying action on disconnect events for a fixed interval to allow late-arriving messages to be processed), polling or re-query patterns, and application-layer sequence numbering. Each mitigation imposes trade-offs: debounce windows introduce detection latency for genuine disconnect events and may suppress legitimate notifications; polling adds network overhead and is unsuitable for passive sensors.