Matching topic for subscribe/unsubscribe

[juliandroid]

I see different behaviour between subscribing in different order:

1. topic/test/#
2. topic/test/another

and in reverse:

1. topic/test/another
2. topic/test/#

In the first case match(topic) @ router.go:108 returns true when you try to subscribe for topic/test/another, which effectively overwrites the wildcard subscription and leaves only topic/test/another

However in the second case, for the second subscription call to topic/test/# does not match, so effectively you have both subscriptions.

I'm not sure what is correct behaviour, but as far as I understand this:

If a Server receives a SUBSCRIBE Packet containing a Topic Filter that is identical to an existing Subscription’s Topic Filter then it MUST completely replace that existing Subscription with a new Subscription.

As if two topic patterns matches literally, so both topic/test/another and topic/test/# are not identical (second one is more broader).

I.e.:
When Clients make subscriptions with Topic Filters that include wildcards, it is possible for a Client’s subscriptions to overlap so that a published message might match multiple filters. In this case the Server MUST deliver the message to the Client respecting the maximum QoS of all the matching subscriptions

I would expect to have both. From current implementation I see func match(route []string, topic []string) that is called recursively which seems to perform level by level checks instead of simple string match. What is the rational? Maybe I miss key point in the specification that requires that logic?

[alsm]

Interesting, yeah, this has been wrong for a long time. I probably just used the match for comparison as I was thinking about topics and delivery rather than it was a comparison.

[MattBrittan]

I believe that this was addresses in PR #388 so am closing this (age/inactivity). Please feel free to reopen if you believe it has not been addressed.