MQTT Publish/Subscribe

Publish

Each message must include a topic, through which the broker delivers the message to clients interested in that topic. The specific content of the message is passed in binary form. MQTT is agnostic to the content of the message, and the client can send data in any format, such as binary data, text data, XML data, or JSON data, etc.

Format

The topic is a hierarchical structure composed of strings separated by slashes, for example, “home/bedroom/temperature”.

Quality of Service

Quality of Service determines the guarantee level for message delivery to the target. Quality of Service is divided into three levels: 0, 1, 2. 0 means the message is delivered at most once, and if it fails, no retries will be made. 1 means the message is delivered at least once, and if the recipient does not explicitly receive it (returns acked), it will continue to retry sending. 2 means the message is delivered exactly once.

Retain Flag

The retain flag determines whether the message is retained as the latest message for this topic. When a new client subscribes to this topic, it will receive the latest retained message for this topic. For each topic, there can be at most one retained message, but there may also be none.

Message Payload

The message payload is the specific content of the message. MQTT is unaware of the content of the message, so users can send any message.

Duplicate Field

When the quality of service of the message is greater than 0, this field is set when the message is retried.

QoS Levels

MQTT supports three Quality of Service (QoS) levels. They are defined as follows:

1. QoS 0: At most once delivery
   This is the lowest level of service. A message is delivered at most once, and it might not be delivered at all if network disruptions occur. The message is sent from the sender (publisher) to the receiver (subscriber) without any confirmation message. There is no retransmission of the message.

2. QoS 1: At least once delivery
   In this level of service, a message is assured to be delivered at least once to the receiver. After the sender sends the message, it stores a copy of the message until it receives a PUBACK message from the receiver. If the sender does not receive a PUBACK message within a certain period, it will resend the message.

3. QoS 2: Exactly once delivery
   This is the highest level of service, where a message is assured to be delivered exactly once. This is achieved using a four-step handshake process:

   • The sender sends the message and keeps a copy of it. The message is marked as “unconfirmed”.
   • The receiver responds with a PUBREC message to acknowledge receipt of the message.
   • The sender receives the PUBREC message, removes the “unconfirmed” mark from the stored message, and responds with a PUBREL message.
   • Finally, the receiver responds with a PUBCOMP message to confirm that it has processed the PUBREL message. The sender can now safely delete the message from its storage.

Each level of service has different trade-offs in terms of network traffic, latency, and complexity. You should choose the appropriate QoS level based on the specific requirements of your application.

Subscribe

If no client subscribes to a topic, any messages published to that topic won’t be received by any client. Clients need to send a subscription request to the broker in order to subscribe to the corresponding topic.

Format

Packet Identifier

This is a unique identifier for each SUBSCRIBE message. Both the broker and client maintain their own Packet Identifier for each ongoing conversation. The identifier doesn’t need to be globally unique, but it does need to be unique within the scope of the client-broker communication session.

Subscription List

A single SUBSCRIBE message can request multiple topic subscriptions. Each subscription request needs to include the topic to be subscribed to and the desired Quality of Service (QoS) level. The topic string in the SUBSCRIBE packet can include wildcard characters. If the same topic is subscribed to with different QoS levels (i.e., overlapping subscriptions), the broker will deliver messages to the client at the highest QoS level that has been granted.

Subscription Acknowledgement

After the client requests to subscribe to a topic, the broker will respond with a SUBACK.

Format

The message includes a Packet Identifier that matches the one in the subscription request, as well as a set of return codes, as shown below:

Packet Identifier

This Packet Identifier should match the one in the corresponding subscription request.

Return Codes

The return codes correspond to the QoS-topic list in the subscription request, confirming the result of each subscription one-to-one. If successful, the corresponding Quality of Service (0/1/2) will be returned. If the subscription fails, the return code will be 0x80 (128 in decimal).

After the client initiates a subscription and receives a successful subscription acknowledgement, this client will be able to normally receive any subsequent messages sent to that topic.

Unsubscribe

The UNSUBSCRIBE packet is as follows, mainly containing a Packet Identifier and a list of topics to be unsubscribed:

Unsubscribe Acknowledgement

The return for an UNSUBSCRIBE request is an UNSUBACK message that only contains a Packet Identifier matching the one in the UNSUBSCRIBE request. An UNSUBACK is sent regardless of whether the topic was previously subscribed to or not.

Conclusion

MQTT message delivery is implemented through subscribing to specific topics, then publishing messages to those topics.

There’s no need to create and maintain topics before publishing, nor worry about whether there are clients subscribing to specific topics.

The Publish/Subscribe model decouples publishers and subscribers, making it easier to arrange various business scenarios, such as implementing grouping, broadcasting, etc.

However, the Publish/Subscribe model also brings a challenge: if the publisher wishes to be aware of the subscriber’s receipt of a message, this can only be accomplished at the application layer. For example, after a subscriber receives a message, it can publish a confirmation message to the publisher through another topic.