Basic Profile Compliance

General Features

Feature

Compliance Status

Extensions

Web Socket transport

Transport and Session Lifetime

Each session establishes a new transport connection.

Close session and connection on protocol errors

Serializations

JSON, Msgpack

BERT, Erlang

Validation of custom object keys using regex [a-z0-9]{3,}

🔜

No Polymorphism, avoid empty arguments and keyword arguments

Session Lifecycle

Agent Identification

PubSub Features

Feature

Implementation Status

Extensions

Ordering Guarantees

Partial, see NC1

Subscription (and Subscription ID) to be shared amongst subscribers to the same topic.

Partial, see NC2

Non-compliance Cases

NC1: PubSub Ordering Guarantees

Requirement
Implementation
Rationale
Roadmap
Requirement

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 1and 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.

Implementation

TBD

Rationale

TBD

Roadmap

TBD

NC2: Bondy does not reuse subscription IDs across subscribers

Requirement
Implementation
Rationale
Roadmap
Requirement

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.

Implementation

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.

Rationale

Bondy was designed as a distributed router with continuous availailability 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 (concensus) and thus we do not support it.

Roadmap

No changes planned.

NC3: Bondy does not reuse registration IDs across callees

Requirement
Implementation
Rationale
Roadmap
Requirement

The WAMP protocol is not clear on whether a registration ID is shared or nor amongst multiple Callees registering the same URI under the shared registration feature.

According to section 14.3.7.1.3.5. the call to wamp.registration.list_callees(RegistrationId)retrieves a list of session IDs for sessions currently attached to the registration, which implies all Callees shared the same RegistrationId. Crossbar.io documentation says the same.

Implementation

Every registration gets its own registration ID, which eases the implementation of the replica merge algorithm as it is natural and requires no coordination.

Rationale

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

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

Roadmap

No changes planned.

RPC Features