Compliance ​

Pub/Sub: Ordering Guarantees

The ordering guarantees are as follows:

If Subscriber A is subscribed to both Topic 1 and Topic 2, and Publisher B first publishes an Event 1 to Topic 1 and then an Event 2 to Topic 2, then Subscriber A will first receive Event 1 and then Event 2. This also holds if Topic 1 and Topic 2 are identical.

In other words, WAMP guarantees ordering of events between any given pair of Publisher and Subscriber.

Further, if Subscriber A subscribes to Topic 1, the SUBSCRIBED message will be sent by the Broker to Subscriber A before any EVENT message for Topic 1.

There is no guarantee regarding the order of return for multiple subsequent subscribe requests. A subscribe request might require the Broker to do a time-consuming lookup in some database, whereas another subscribe request second might be permissible immediately.

Pub/Sub: Subscription (and Subscription ID) to be shared amongst subscribers to the same topic

The WAMP protocol requires a subscription to be shared amogst subscribers to the same topic.

A subscription is created when a client sends a subscription request for a topic where there are currently no other subscribers. It is deleted when the last subscriber cancels its subscriptions, or its session is disconnected.

A subscriber receives a subscription ID as the result of a successful subscription request. When an second subscriber issues a subscription request for the same topic, then it receives the same subscription ID.

A subscriber receives a subscription ID as the result of a successful subscription request. When an second subscriber issues a subscription request for the same topic, then it receives a different subscription ID.

Sharing a subscription between two or more subscribers in at least two cluster nodes will require coordination (consensus) and thus it is not support it.

Pub/Sub: Registration (and Registration ID) to be shared amongst callees

The WAMP protocol requires a registration to be shared amogst callees to the same procedure.

A registration is created when a client sends a registration request for a procedure where there are currently no other callees. It is deleted when the last callee cancels its registration, or its session is disconnected.

A callee receives a registration ID as the result of a successful registration request. When an second callee issues a registration request for the same procedure, then it receives the same registration ID.

A callee receives a registration ID as the result of a successful registration request. When an second callee issues a registration request for the same procedure, then it receives a different registration ID.

Sharing a registration between two or more callees in at least two cluster nodes will require coordination (consensus) and thus it is not support it.