Unsubscribing a non-owned subscription

[ecorm]

What is the expected behavior of a Broker when a client sends an UNSUBSCRIBE with the ID of an existing subscription, but for which it never subscribed?

For example

Client 1

TX: [SUBSCRIBE,1,{},"topic"]
RX: [SUBSCRIBED,1,42,"topic"] // Subscription ID 42

Client 2

TX: [UNSUBSCRIBE,1,42] // Subscription ID 42
RX: ?

My guess is that the Broker should respond with an ERROR with URI=wamp.error.no_such_subscription. While the subscription does indeed exist, the client issuing the UNSUBSCRIBE is not a subscriber to the topic, so it's like saying "there's no such subscription for you".

This behavior is also what I would expect from a client unsubscribing twice to a subscription it actually owned:

TX: [SUBSCRIBE,1,{},"topic"]
RX: [SUBSCRIBED,1,42,"topic"] // Subscription ID 42
TX: [UNSUBSCRIBE,2,42] // Subscription ID 42
RX: [UNSUBSCRIBED,2]
TX: [UNSUBSCRIBE,3,42] // Subscription ID 42
RX: [ERROR,UNSUBSCRIBE,3,{},"wamp.error.no_such_subscription"]

This way, the broker always applies the same logic without having to remember that a client previously had a subscription to the topic it wants to unsubscribe from.

The same question applies to unregistering an non-owned registration.

Please let me know if my reasoning is correct.

[Jopie64]

I think an UNSUBSCRIBE or UNREGISTER should never have any effect on any client other than itself. DEALER should be implemented such that client's can't know about each other's subscriptions/registrations. Registration/subscription ID's of different clients should even be able to overlap.

Also my first hunch about sending an UNSUBSCRIBE to a subscription it doesn't currently own should result in a protocol violation? There can't be races here because of network since a client initiates subscribe/unsubscribe (or registrations) itself. Unless the meta api was used to forcefully unsubscribe someone. So maybe only in that case, no protocol violation since now there can be races?

[ecorm]

DEALER should be implemented such that client's can't know about each other's subscriptions/registrations.

The way I understand it, there is only one subscription ID per topic+match_policy combo, as confirmed by the wamp.subscription.lookup meta procedure.

Several subscribers can associated with the same subscription ID, as confirmed by the wamp.subscription.list_subscribers meta procedure which takes a subscription|id argument and returns a list of subscriber session IDs.

So subscriber IDs are not unique to each subscriber as far as the meta API is concerned.

Unless the meta api was used to forcefully unsubscribe someone. So maybe only in that case, no protocol violation since now there can be races?

So returning an ERROR (instead of a protocol violation abort) makes WAMP more future-proof if such a meta procedure is introduced. A wamp.subscription.remove_subscriber meta-procedure has been proposed in #253.

[Jopie64]

Hmmm... That indeed looks like the model the meta model is exposing indeed... It feels weird to me though...

The model I had in mind was different. If you put it in SQL table terms it would look more or less like this:

erDiagram
  TOPIC {
     int id
     string uri
  }
  SESSION {
    int id
    string ipAddress
    other properties
  }
  SUBSCRIPTION {
     int id
     int idSession
     int idTopic
  }
  TOPIC ||--|{ SUBSCRIPTION: has
  SESSION ||--o{ SUBSCRIPTION: has

This way a sessions subscription to a topic is a totally separate object than another session's subscription to the same topic, of which each hold their own id.
But in the other model, it seems the topic and subscription 'table' seem merged together, which feels odd to me...

In the latter case, why have a subscription id (which is then also a topic id) communicated at all? Why not just always reference topics by Uri's, even when doing unsubscribe?

[ecorm]

In the latter case, why have a subscription id (which is then also a topic id) communicated at all? Why not just always reference topics by Uri's, even when doing unsubscribe?

The topic URI is not enough to unsubscribe. A subscription is associated with a topic URI + match policy combination, where match policy is exact, prefix, or wildcard.

[ecorm]

There can't be races here because of network since a client initiates subscribe/unsubscribe (or registrations) itself. Unless the meta api was used to forcefully unsubscribe someone. So maybe only in that case, no protocol violation since now there can be races?

Another future possibility is if router-side session resuming is ever specified, and the client wants to unsubscribe after resuming when a previous unsubscribe attempt was interrupted by a network failure. So again, returning an ERROR instead of treating a non-owned unsubscription ID as a protocol violation makes things more future-proof.

[oberstet]

The way I understand it, there is only one subscription ID per topic+match_policy combo

yes, correct

Why not just always reference topics by Uri's, even when doing unsubscribe?

because as @ecorm notes, that isn't enough - because of pattern based subs/regs. also, the possible future use he mentions makes a lot of sense.

[KSDaemon]

My thoughts on topic:

1. I like @ecorm's proposal and have the same in my mind.
2. Don't forget that there are IDs of different scopes, and Subscriptions are of router scope and not a session scope. So the same subscription may be returned to different clients.
3. In implementations that I'm aware of - it is impossible to unsubscribe from a subscription not owned by the session itself. And that should be so.
4. I think that unsubscribing from the unexisting subscription should not be a protocol violation even if right now there can be no race condition as I feel that this can lead to possible problems in future extensions. And having ERROR is aligned with our flow in other similar cases.

[oberstet]

In implementations that I'm aware of - it is impossible to unsubscribe from a subscription not owned by the session itself.

Crossbar.io allows that via meta API - kick a subscriber (on a different session) from a subscription:

https://github.com/crossbario/crossbar/blob/03d7057ee18a0d1e59b33bf1633ee246c1cf908a/crossbar/router/service.py#L549

https://github.com/crossbario/crossbar/blob/03d7057ee18a0d1e59b33bf1633ee246c1cf908a/crossbar/router/service.py#L509

[KSDaemon]

Yeah! Meta RPCs are special cases sometimes intended exactly for such things :)

[KSDaemon]

@Jopie64 you forgot about wildcards and prefixes. For simple exact topics, your scheme may be ok :)
But when we deal with pattern-based subscription - things get more complicated.
Clients subscribe to an URI + matching options. Client A may subscribe to exact URI - this will be subscription 1, Client B may subscribe to prefix-based URI - this will be subscription 2, but they both can receive the same event if it matches URI of first subscription and has the same prefix of the second.

As an event must be delivered to all clients connected to the router - it is logical that subscriptions are in the router scope, but not in the session. The unsubscribing and unregistering on the other hand always happens in the context of exact session, and router knows what subscriptions that session has.

[oberstet]

yes, absolutely. we've arrived at this solution (sub/reg IDs and how they are used) because of this. and also save wire space (transmitting an int in events/calls is better than a whole string identifying a sub/reg)