Compliance

This section describes how compliant is Bondy's WAMP implementation.

Overview

Bondy tries to be as compliant as possible with the WAMP Specification. However, because the specification was not designed from the ground up to consider a distributed router there are some requirements we cannot (and/or we do not want to) be compliant with.

The following two sections go into a detail compliance analysis listing what WAMP features Bondy implement and those cases in which Bondy does not comply with the Specification. In those particular cases you will also find an explanation of the rationale and the roadmap behind them.

Basic Profile

General Features

Feature	Status	Extensions	Roadmap
Web Socket transport	✔️
Batched Web Socket transport	❌		Yes
Raw Socket transport	✔️
Longpoll transport	❌
Transport and Session Lifetime	✔️ Each session establishes a new transport connection
Close session and connection on protocol errors	✔️
Serializations: Support JSON and Msgpack	✔️	BERT, Erlang (subset)	CBOR, Flatbuffers
Validation of custom attribute keys using regex	✔️
No Polymorphism, avoid empty arguments and keyword arguments	✔️
Agent Identification	✔️
Session Meta API	✔️

Pub/Sub Features

Feature	Status	Extensions	Roadmap
Ordering Guarantees	Partial, see NC1		Yes
Subscription (and Subscription ID) to be shared amongst subscribers to the same topic.	❌ see NC2		No

Routed RPC Features

Feature	Status	Extensions	Roadmap
Registration (and Registration ID) to be shared amongst callees	❌ see NC2		No

Advanced Profile

General Features

Feature	Status	Extensions	Roadmap
Challenge-response authentication	✔️
Ticket authentication	✔️	Allows Single Sign-on to multiple realms
Cookie authentication	❌		No

Pub/Sub Features

Feature	Status	Extensions	Roadmap
Subscriber black-/white-listing	✔️
Publisher exclusion	✔️
Publisher identification	✔️
Publication trust-levels	✔️
Subscription Meta API	✔️
Pattern-based subscription	✔️
Sharded subscription	❌		Yes
Event history	❌		Yes
Topic reflection	❌		Yes

Routed RPC Features

Feature	Status	Extensions	Roadmap
Call Timeout	✔️
Call Canceling	✔️
Caller Identification	✔️
Call Trust-levels	✔️
Registration Meta API	✔️
Pattern-based Registration	✔️
Shared Registration	✔️
Sharded Registration	❌		Yes
Registration Revocation	❌		Yes
Procedure Reflection	❌		Yes
Progressive Call Results	❌		Yes
Progressive Calls	❌		Yes

Non-compliance Cases

NC1

• Requirement
• Implementation
• Rationale
• Roadmap

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.

A Bondy node will deliver the events in order locally i.e. when Publisher and Subscriber are on the same node. However, when it comes to publishing events to a remote subscriber, Bondy tries its best to deliver them in the order required by the protocol, but this is not currently guaranteed.

Bondy was designed as a distributed router with continuous availability as its main goal. Bondy uses an eventually consistent model avoiding coordination between nodes at all cost.

Bondy plans to implement stronger delivery order guarantees to comply with the protocol requirements and also enable new features, such as guaranteed message delivery.

NC2

• Requirement
• Implementation
• Rationale
• Roadmap

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 subscription is created when a client sends a subscription request for a topic when itself does not have an existing subscription for the same topic. It is deleted when the subscriber cancels the 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 a different subscription ID.

Bondy was designed as a distributed router with continuous availability as its main goal. Bondy uses an eventually consistent model avoiding coordination between nodes at all cost.

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.

No changes planned.

NC3

• Requirement
• Implementation
• Rationale
• Roadmap

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 registration is created when a client sends a registration request for a procedure when itself does not have an existing registration for the same procedure. It is deleted when the callee cancels the 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 a different registration ID.

Bondy was designed as a distributed router with continuous availability as its main goal. Bondy uses an eventually consistent model avoiding coordination between nodes at all cost.

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.

No changes planned.