Subscription identifier

Clients can specify a so-called subscription identifier when creating a subscription. The message broker then internally stores a mapping between this subscription and the respective identifier. As soon as a message is sent from the broker to the client, the subscription identifier is also transmitted to the client. The client then has the option of assigning the message internally based on the subscription identifier. The following figure illustrates this relationship once again:

Subscription identifier 1:

In this sample, the MQTT client creates four subscriptions on the left side, each to partially "overlapping" topics using wildcards. Now the right MQTT client publishes a message on the topic /car/red/convertible.

Now two options are available.

  1. Unoptimized variant: The subscriber receives three MQTT messages (publishes) from the broker. Each message contains the respective subscription identifier. In the TwinCAT PLC, based on our sample IotMqttv5Sample, three messages would thus end up in the message queue. Example screenshot from Wireshark when receiving the three messages:
    Subscription identifier 2:
    Mosquitto Broker version 2.0.15 uses this transfer type by default.
  2. The subscriber contains only one MQTT message from the broker, where this message contains a list of subscription identifiers. In the above sample, the identifiers 1, 2 and 3. In this case, only one message would end up in the message queue in the TwinCAT PLC. This message then contains an array of the subscription identifiers. Example screenshot from Wireshark when receiving the message:
    Subscription identifier 3:
    Subscription identifier 4:

The HiveMQ CE Broker in version 2023.3 uses this transfer type by default.

Both transmission types are permitted according to the MQTT specification.