MQTT Subscription Identifier Details

Why do you need a subscription identifier

In the implementation of most MQTT clients, the callback mechanism is used to realize the processing of newly arrived messages.

But in the callback function, we can only know what the subject name of the message is. If it is a non-wildcard subscription, the topic filter used when subscribing will be exactly the same as the topic name in the message, so we can directly establish the mapping relationship between the subscription topic and the callback function. Then when the message arrives, find and execute the corresponding callback function according to the topic name in the message.

But if it is a wildcard subscription, the topic name in the message and the topic filter when subscribing will be two different strings. Only by matching the topic name in the message with the original subscription one by one can we determine which callback function should be executed . This obviously greatly affects the processing efficiency of the client.

In addition, because MQTT allows a client to establish multiple subscriptions, when a client uses a wildcard subscription, a message may match multiple subscriptions of a client at the same time.

For this case, MQTT allows the server to send a message for these overlapping subscriptions, and also allows the server to send only one message for these overlapping subscriptions. The former means that the client will receive multiple duplicate messages.

Regardless of the former or the latter, the client cannot determine which subscription or subscriptions the message came from. Because even if the client finds that a message matches its two subscriptions at the same time, it cannot guarantee whether the two subscriptions have been successfully created when the server forwards the message to itself. So, the client fails to trigger the correct callback for the message.

How Subscription Identifiers Work

To solve this problem, MQTT 5.0 introduces subscription identifiers. Its usage is very simple. The client can specify a subscription identifier when subscribing, and the server needs to store the mapping relationship between the subscription and the subscription identifier. When there is a PUBLISH packet matching the subscription to be forwarded to the client, the server will return the subscription identifier associated with the subscription to the client together with the PUBLISH packet.

If the server chooses to send messages once for overlapping subscriptions, each PUBLISH packet should contain the subscription identifier matching the subscription, and if the server chooses to send only one message for overlapping subscriptions, then the PUBLISH packet will Contains multiple subscription identifiers.

The client only needs to establish a mapping between the subscription identifier and the callback function, and can know which subscription the message comes from and which callback function should be executed through the subscription identifier in the message.

In the client, the subscription identifier is not part of the session state, and it is entirely up to the client to associate the subscription identifier with what content. So in addition to the callback function, we can also establish a mapping between the subscription identifier and the subscription topic, or establish a mapping with the Client ID. The latter is useful in gateways that forward messages from the server to clients. When a message arrives at the gateway from the server, the gateway can know to which client the message should be forwarded based on the subscription identifier, without re-doing topic matching and routing.

A subscription message can only contain one subscription identifier. If there are multiple subscription requests in a subscription message, the subscription identifier will be associated with these subscriptions at the same time. So try to make sure that associating multiple subscriptions to the same callback is intentional.

How to use the subscription identifier

1. Access MQTTX Web on a web browser .

2. Create an MQTT connection using WebSocket and connect to a free public MQTT server:

   

3. After the connection is successful, we first subscribe to the topic mqttx_4299c767/home/+and specify the Subscription Identifier as 1, then subscribe to the topic mqttx_4299c767/home/PM2_5and specify the Subscription Identifier as 2. Since the public server may be used by many people at the same time, in order to avoid repeating the topic with others, here we use the Client ID as the topic prefix:

   

   

4. After the subscription is successful, we mqttx_4299c767/home/PM2_5publish a message to the topic. We will see that the current client has received two messages, and the Subscription Identifiers in the messages are 1 and 2 respectively. This is because the implementation of EMQX sends a message separately for overlapping subscriptions:

   

5. And if we mqttx_4299c767/home/temperaturepublish a message to the topic, we will see that the Subscription Identifier in the received message is 1:

   

So far, we have demonstrated how to set Subscription Identifier for subscription through MQTTX. If you are still curious about how to trigger different callbacks based on Subscription Identifier, you can get the Python sample code of Subscription Identifier here .

Copyright statement: This article is original by EMQ, please indicate the source for reprinting.
Original link: https://www.emqx.com/zh/blog/subscription-identifier-and-subscription-options