WAMP V2 interpretation about wamp-proto HOT 5 CLOSED

Yes, there is a fixed set of roles defined in WAMPv2, and each peer can have one or more roles at the same time. For each role, there are optional features. Support for these optional features is announced by a peer (for each role it supports) in the HELLO message during Session establisment. And yes, it makes sense to store the peer's features. E.g. a Dealer that knows that a Callee does not support call canceling should not send INTERRUPT messages.

Serializations are aspects of a transport. A transport can also be a "direct-call" transport with no actual serialization at all. This is the case e.g. here https://github.com/tavendo/AutobahnPython/tree/master/examples/twisted/wamp/basic#application-component-deployment when an application component is run directly next to the router within the same program (OS process).

Regarding "channels" and "transports": these really mean the same. We should replace "channel" in the spec with "transport".

A Session runs over a transport. Currently, only 1 Session can run over a transport at any given point in time. But this is probably going to change (#39).

Beside "Transport" and "Session", we will likely introduce "Realm": a WAMP routing namespace and administrative domain:

• A Session exists between two Peers.
• Zero or more Sessions run over a Transport.
• Each Session is attached to a Realm.
• Transports are reusable.
• A Realm can (obviously) have many Sessions attached.
• Sessions for a given Realm can come in via different Transports.

A Peer is the ephemeral "thing" at (both) ends of a ephemeral Session. It does not have an existence separate from a Session. In this respect, above drawing is probably not yet correct. A Session "has" two Peers. Each Peer "has" roles. The peer's role instance has features enabled/disabled. The abstract features are attributes of the abstract role.

A Session "has" a Transport (but that Transport can run different Sessions).

from wamp-proto.

Which roles are you planning for? Which WebSocket (or other transport)? JSR356?

from wamp-proto.

Thanks for your comments,

Right now I'm starting to develop a WAMP V2 implementation on Java and C#, I will first start with the Java impl and this is my roadmap (release dates are not defined yet but I need to do it fast):

Roadmap for V1:

• RPC Roles (CALLER, DEALER, CALLEE)
• Websocket Transport (JSR356)
• Http Streaming Transport (JSR340, Async Servlets). Sometimes I have problems with websockets running over proxies so I need to develop a "backup" transport.
• JSON Serialization (JSR353, JSONP)

Roadmap for V2:

• PUB/SUB Roles (SUBSCRIBER/PUBLISHER/BROKER)

Roadmap for V3:

• Role features
• Advanced PUB/SUB and RPC

Roadmap for V4

• Other missing features

Do you have any release date for the final specification?

from wamp-proto.

In fact, we have plans for a JSR356 WAMP implementations also (Caller, Callee, Publisher, Subscriber roles): https://github.com/tavendo/AutobahnPython/blob/master/doc/WAMPv2%20Integration%20Options.pdf?raw=true

This won't get Broker/Dealer roles, since application code is better run outside Routers in general. And Crossbar.io will soon get WAMPv2 support and then provides a full-featured WAMPv2 router.

Do you need to implement router roles (broker/dealer)? That is: are you planning to do a custom router?

We are currently implementing WAMPv2 in AutobahnJS (alpha code: https://github.com/tavendo/AutobahnJS/blob/wamp2/work/session.js) and start working on Crossbar.io again. http://crossbar.io/

The final WAMPv2 spec will probably still take till March, since we need to make sure it really works when actually being implemented. This includes advanced stuff done in Crossbar.io, like clustered routers, and multitenancy (multiple routing realms).

from wamp-proto.

WAMP 2 Basic Profile is considered stable now: https://github.com/tavendo/WAMP/blob/master/spec/basic.md

from wamp-proto.