You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see different behaviour between subscribing in different order:
topic/test/#
topic/test/another
and in reverse:
topic/test/another
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?
The text was updated successfully, but these errors were encountered:
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.
I see different behaviour between subscribing in different order:
topic/test/#
topic/test/another
and in reverse:
topic/test/another
topic/test/#
In the first case
match(topic) @ router.go:108
returns true when you try to subscribe fortopic/test/another
, which effectively overwrites the wildcard subscription and leaves onlytopic/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
andtopic/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?The text was updated successfully, but these errors were encountered: