MQTTv5: Overlapped subscriptions considered cross client

[mauricek]

Consider the following setup:

• ClientA with subscription subA1 on topic foo and subscription id 1
• ClientB with subscription subB1 on topic foo and subscription id 2
• ClientB with subscription subB2 on topic foo/# and subscription id 3

When a message on topic foo is published from another client, the standard says: " If the Server sends a single copy of the message it MUST include in the PUBLISH packet the Subscription Identifiers for all matching
subscriptions which have a Subscription Identifiers, their order is not significant [MQTT-3.3.4-4].
If the Server sends multiple PUBLISH packets it MUST send, in each of
them, the Subscription Identifier of the matching subscription if it has a Subscription Identifier [MQTT-3.3.4-5].
"

This is true for Client B, with paho.mqtt.testing it receives a PUBLISH with the ids 2 and 3 to indicate the overlap. subA also receives the message. However, there is contains the ids 1, 2 and 3, meaning the IDs of a separate client.

Overlapped subscriptions should be understood as per client instance, not over the whole subscription space. Especially as multiple clients could use the same ids.

Expected result:

• subB1 receives one PUBLISH including subscriptions ids 2, 3
• subB2 receives one PUBLISH including subscriptions ids 2, 3
• subA1 receives one PUBLISH including subscription id 1

Alternatively (as done on other MQTT5 implementations)

• subB1 receives two PUBLISH messages, each containins just one subscription id (2 or 3)
• subB2 receives two PUBLISH messages, each containins just one subscription id (2 or 3)
• subA1 receives one PUBLISH including subscription id 1

Actual result:

• subB1 receives one PUBLISH including subscriptions ids 2, 3
• subB2 receives one PUBLISH including subscriptions ids 2, 3
• subA1 receives one PUBLISH including subscription id 1, 2, 3

[icraggs]

Thanks, I've added a fix and a test.

[mauricek]

Works nicely. Thank you.