An Introduction to MQTT

Author: Liyan Ibrahim

MQTT, which stands for Message Queuing Telemetry Transport, is a messaging protocol designed for real-time communication between devices in an IP-based networked device ecosystem. It operates over TCP/IP using a publish/subscribe model, where devices (referred to as clients) can publish messages to specific topics or subscribe to topics to receive messages.

MQTT is optimized for environments with limited resources, including devices with constrained computing power and low network bandwidth. It supports scalability, capable of handling a large number of connected devices, while ensuring lightweight, efficient, and bi-directional communication. The protocol can also be secured through SSL/TLS encryption, ensuring secure data transmission.

MQTT clients are compact and resource-efficient, allowing them to operate on computationally limited systems, such as microcontrollers or devices with constrained memory and processing power, making the protocol ideal for embedded systems.

Diagram of an MQTT transaction. A temperature sensor publishes readings to an MQTT broker, and two clients, a mobile client and a backend database client, subscribe to the sensor's MQTT topic to get automatic updates.

Figure 1: MQTT protocol example. A temperature sensor publishes readings to an MQTT broker, and two clients, a mobile client and a backend database client, subscribe to the sensor’s MQTT topic to get automatic updates.

Broker 

An MQTT broker is a key intermediary in the MQTT messaging protocol, facilitating communication between MQTT clients. The broker receives messages published by clients, filters them by topic, and distributes the messages to subscribed clients. It plays a critical role in enabling a lightweight, scalable, and reliable mechanism for information sharing in networked environments, such as IP-based device ecosystems.

Unlike a traditional server, which may handle a wide range of general computing tasks, an MQTT broker is specifically designed to handle real-time message distribution between devices in a publish/subscribe model. It does not generate or consume data directly but rather routes messages between clients. Databases, on the other hand, are often used in conjunction with brokers to store persistent data that clients may retrieve or write to, typically supporting more complex data management beyond the scope of MQTT’s transient messaging.

MQTT brokers are essential for the scalability of networks, as they can manage a large number of simultaneous client connections. They also support integration with other protocols and cloud platforms, making them integral to comprehensive solutions in Internet of Things (IoT) ecosystems.

While MQTT brokers are robust, their capacity is limited by factors such as server hardware, network bandwidth, and broker software configurations. The performance of a broker is heavily influenced by the hardware running it. Energy consumption and processing power are critical factors — for example, higher traffic loads or resource-intensive operations like message filtering, encryption, or logging can strain the broker’s performance. Under optimal conditions, most brokers can handle thousands or even millions of simultaneous connections, but as the number of connected devices grows, the broker may experience performance degradation. This can result in delays, loss of messages, or resource exhaustion, depending on the system’s limits.

Publish/Subscribe 

The Publish-Subscribe pattern is central to MQTT and operates within the broker, enabling a highly decoupled communication model. In this pattern, clients that send messages (publishers) are separated from those that receive messages (subscribers), allowing them to exchange information without requiring direct connections or awareness of each other’s existence.

This pattern is not unique to MQTT; it is a widely used mechanism in other protocols and systems, such as AMQP, Redis Pub/Sub, and Google Cloud Pub/Sub, due to its scalability and flexibility in handling asynchronous communication.

In the MQTT model, publishers send messages with associated topics to the broker, while subscribers register their interest in specific topics. The broker then ensures that subscribers receive the messages relevant to the topics they are subscribed to.

This pattern has four main components: Publisher, Subscriber, Broker, and Topic.

Broker

An MQTT broker receives messages published by clients, filters the messages by topic, and distributes them to subscribers, as described above

Topic

A topic is a hierarchical string that acts as an identifier for a specific message channel. It is organized in levels, separated by slashes (/), for example, sensor/1/temperature.

Topic Wildcards: MQTT supports wildcards for flexible subscriptions, enabling clients to subscribe to multiple related topics efficiently. The + wildcard matches a single level (e.g., sensor/+/temperature matches sensor/1/temperature and sensor/2/temperature), while the # wildcard matches all subsequent levels (e.g., sensor/# matches sensor/1/temperature and sensor/1/humidity).

Subscribers can subscribe to multiple topics simultaneously using topic wildcards. This allows them to receive messages on multiple topics with a single subscription.

Publisher

A publisher is a device or program responsible for sending messages to a specific topic. It operates independently of subscribers and does not need to know whether any subscribers are online at the time of publishing. Publishers send messages one topic at a time, making the process lightweight and efficient.

Subscriber

A subscriber is a device or program that registers interest in specific topics to receive messages. Subscribers can subscribe to multiple topics simultaneously, allowing them to gather diverse data streams.

Shared Subscriptions

MQTT supports shared subscriptions, enabling multiple subscribers to share the message-processing load associated with a single topic subscription. In this setup, messages published to the shared subscription are distributed among the subscribers in a load-balanced manner, with each subscriber handling only a portion of the messages. This is particularly useful in large-scale systems where high message throughput or intensive processing requirements might overwhelm a single subscriber.

References