Publish, subscribe and topics
MQTT separates the devices that produce data from the applications that use it. A client publishes a message to a topic, a text name with levels separated by slashes, such as “plant/boiler/temperature”. Other clients subscribe with topic filters, and the server delivers each message to every client whose filter matches. The publisher does not need to know who is listening, and subscribers do not need to know who published. The specification calls this one-to-many distribution and decoupling of applications.
Topic filters can use two wildcards. A plus sign matches exactly one level, so “plant/+/temperature” matches every machine’s temperature. A number sign at the end matches any number of levels, so “plant/#” matches everything under “plant”. The payload itself is opaque to the protocol: MQTT carries bytes and leaves their format to the application.
The OASIS specification describes MQTT as light weight, open and simple, suited to machine-to-machine and Internet of Things settings “where a small code footprint is required and/or network bandwidth is at a premium”. It runs over TCP/IP or any other connection that is ordered, lossless and bi-directional, and the standard also defines how to carry it over WebSocket. mqtt.org notes that it can be encrypted with TLS.
Three delivery levels
Each message is published with a quality of service (QoS) level:
- QoS 0, at most once. No acknowledgement and no retry. The message arrives once or not at all. The specification suggests it for ambient sensor data, where a lost reading does not matter because the next one follows soon.
- QoS 1, at least once. The receiver acknowledges with a PUBACK packet, and if the connection drops first, the sender resends the message when it reconnects to the same session. The message is assured to arrive, but duplicates can occur.
- QoS 2, exactly once. A two-step acknowledgement makes sure the message is neither lost nor duplicated, at extra overhead. The specification’s example is billing, where a duplicate could mean a wrong charge.
These guarantees cover one hop at a time: publisher to server, then server to subscriber. The specification notes that the QoS used on the outbound leg can differ from the inbound one. A subscriber’s acknowledgement also says nothing about whether the application behind it processed the message, which is why delivery, acceptance and commit are worth tracking separately. The general trade-off is covered in at most once, at least once and exactly once.
On ordering, the server must by default forward messages on a topic from a given client, at the same QoS, in the order it received them.
Sessions, retained messages and wills
A session is the state the client and server keep between connections. On the server it includes the client’s subscriptions, QoS 1 and QoS 2 messages not yet fully acknowledged, QoS 1 and QoS 2 messages waiting to be sent to the client, and optionally QoS 0 messages. If a client reconnects to an existing session, both sides must resend unacknowledged messages. mqtt.org points to these persistent sessions as the feature that helps devices on unreliable cellular networks.
MQTT 3.1.1 controls this with a Clean Session flag. MQTT 5.0 splits it into a Clean Start flag and a Session Expiry Interval, in seconds, that says how long to keep the session after a disconnect. If the interval is zero or absent, the session ends when the connection closes.
Two more features help with devices that come and go:
- Retained messages. A message published with the retain flag is stored by the server as the latest value for its topic and sent to future subscribers when they subscribe, so a new dashboard sees the last reading straight away.
- Will messages. A client can leave a message for the server to publish if its connection closes without a proper disconnect, so others learn it has gone. MQTT 5.0 adds a delay so that a brief interruption does not trigger it.
A Keep Alive interval, set in seconds, is the longest gap allowed between control packets, which lets a dead connection be noticed instead of left open.
What MQTT 5.0 added
Version 5.0 kept the same model and added features. Its summary of new features includes session expiry, message expiry, reason codes on every acknowledgement, shared subscriptions that spread a topic’s messages across several consumers, topic aliases that replace a long topic name with a small number to cut packet overhead, flow control over how many reliable messages are in flight, and user properties carried with messages.
MQTT when devices go offline
MQTT assumes a connection to a broker. The broker has to be reachable, not necessarily on the internet: a broker on the same local network serves the clients on it. What the standard does not cover is data a device produces while it can reach no broker at all. The client’s session state holds only messages already sent to the server and not yet fully acknowledged, so buffering new readings during a long outage is up to the client library or the application. That means choosing where to store them, how many to keep, and how to send them once a backhaul link returns.
Where devices are out of range of any broker, data has to travel some other way first, such as hop by hop between nearby devices to one that has a link, before a gateway publishes it.