I have a question about subscriptions in Paho and how applications can manage disparate topics (allowing for wildcards). We're interested because we're providing a layer to manage all this stuff to both simplify life for the developers and so we can later use non-MQTT pub/sub under the covers if desired.
An example is probably the best way to explain. Let's say we have two separate modules in our program:
get_all_info() subscribes for a short time to the topic fleet/vehicle-N/# to get all information for a specific vehicle N.speed_mon(), interested only in the speed of all vehicles, subscribes to fleet/+/speed for the duration of the program.Consider the sequence(a):
speed_mon() subscribes to fleet/+/speed.get_all_info() subscribes to fleet/vehicle-17/# and gets information.get_all_info() unsubscribes to fleet/vehicle-17/#.Will the third operation affect the first? In other words, will we still get messages of topic fleet/vehicle-17/speed?
If the unsubscribe is a simple reversal of a specific subscription, it will disable only the subscription created in the second bullet point.
If it uses the filter to disable all matching subscriptions (in the sense of wildcards), it will affect the first subscription as well.
(a) Ignore the fact for now that we would be better off with get_all_info() subscribing to fleet/# for the duration of the program and never unsubscribing, instead just caching messages into local storage. This is a contrived example. We have no control over how clients will use our layer.
I believe that the MQTT specs are pretty clear on this. The v3 and v5 text is similar; v3 states:
The Topic Filters (whether they contain wildcards or not) supplied in an UNSUBSCRIBE packet MUST be compared character-by-character with the current set of Topic Filters held by the Server for the Client. If any filter matches exactly then its owning Subscription is deleted, otherwise no additional processing occurs [MQTT-3.10.4-1].
So it's a character-by-character comparison; unsubscribing to fleet/vehicle-17/# will have no impact on the subscription to fleet/+/speed.
Note that some libraries may not implement this correctly when it comes to mapping incoming messages to callbacks (the go library used to have this wrong).
Perhaps a more interesting question is (you did not ask this but it may have an impact):
If I'm subscribed to both
fleet/+/speedandfleet/vehicle-17/#will I get multiple copies of messages on thefleet/vehicle-17/speedtopic.
The behaviour here is a little more subject to implementation detail in v3 ( spec) but clearly defined in v5 due to the introduction of subscription identifiers (spec).