Publish/Subscribe Architecture
MQTT uses a publish/subscribe (pub/sub) architecture for message exchange. In this model, clients that send data are publishers and clients that receive data are subscribers. A central server, the broker, routes messages between them.
Publishers and subscribers operate independently. A publisher sends a message to the broker without knowing which clients receive it. A subscriber receives messages from the broker without knowing which client sent them. This separation is decoupling. It has three dimensions:
-
Space decoupling: Publishers and subscribers do not need each other’s IP addresses. They only need the broker’s address.
-
Time decoupling: Publishers and subscribers do not need to run at the same time. The broker stores messages for offline clients when configured to do so.
-
Synchronization decoupling: Publishing and receiving do not block each other.
Topics
The broker routes messages using topics.
A topic is a hierarchical string that uses forward slashes as delimiters, for example factory/line1/temperature.
Publishers assign a topic to each message. Subscribers specify the topics they want to receive. The broker delivers each message to all subscribers whose topic filter matches.
Topic filters use wildcards to match multiple topics:
-
` matches a single level: `factory//temperaturematchesfactory/line1/temperatureandfactory/line2/temperature. -
matches all remaining levels:factory/matches all topics underfactory/.
Quality of Service
MQTT provides three Quality of Service (QoS) levels for message delivery:
| Level | Guarantee |
|---|---|
QoS 0 |
At most once. The broker delivers the message once with no confirmation. |
QoS 1 |
At least once. The broker delivers the message one or more times until the client confirms receipt. |
QoS 2 |
Exactly once. The broker and client complete a four-step handshake to guarantee a single delivery. |