Bi-directional RPC

#1

Hi,

We are designing a protocol requiring bi-directional RPC, each party

being RPC client and RPC server.

At the moment, party ‘A’ is establishing a Websocket connection toward

party ‘B’. Then, both are WAMP server and WAMP clients, using the same

Websocket layer:

  • party ‘A’ is Websocket client, WAMP client, and WAMP server

  • party ‘B’ is Websocket server, WAMP server, and WAMP client

The WAMP spec (http://wamp.ws/spec#building_blocks) mentions "default

binding is WebSocket as Transport", but it’s not clear:

  • wether WAMP server should be also Websocket server or not,

  • wether two WAMP client/server connections may use a single Websocket

layer or not.

Most currently existing WAMP implementations seems to assume WAMP server

is also Websocket server.

Really interested in knowing what’s the Autobahn’s opinion about that.

Regards,

Christophe

0 Likes

#2

Hi,

We are designing a protocol requiring bi-directional RPC, each party
being RPC client and RPC server.

Are you designing a new protocol or extending WAMP?

At the moment, party 'A' is establishing a Websocket connection toward
party 'B'. Then, both are WAMP server and WAMP clients, using the same
Websocket layer:
- party 'A' is Websocket client, WAMP client, and WAMP server
- party 'B' is Websocket server, WAMP server, and WAMP client

The WAMP spec (http://wamp.ws/spec#building_blocks) mentions "default
binding is WebSocket as Transport", but it's not clear:
- wether WAMP server should be also Websocket server or not,
- wether two WAMP client/server connections may use a single Websocket
   layer or not.

The transport can be anything providing a reliable, full-duplex, ordered message channel.

The message serialization format is also planned to be pluggable. Currently, the only serialization format specified is JSON.

Most currently existing WAMP implementations seems to assume WAMP server
is also Websocket server.

To the best of my knowledge, there does not yet exist WAMP implementations providing transports different from WebSocket.

···

Am 18.01.2013 22:25, schrieb Christophe Giaume:

Really interested in knowing what's the Autobahn's opinion about that.

Regards,
Christophe

0 Likes

#3

Hi Tobias,

Thanks for the quick answer.

We are designing a protocol requiring bi-directional RPC, each party
being RPC client and RPC server.

Are you designing a new protocol or extending WAMP?

We are designing an application-level protocol on top of WAMP.
Actually, I want to understand if the use I make of WAMP is compliant
to existing specs.

(...)

The transport can be anything providing a reliable, full-duplex, ordered
message channel.

If I understand correctly, using a single Websocket layer for two
symmetric WAMP connections is OK. Isn't it? There's no technical
problems, I've a working implementation. But I'm wondering about the
WAMP compliancy.

(...)

To the best of my knowledge, there does not yet exist WAMP implementations
providing transports different from WebSocket.

Yes, and it seems there's all assuming the WAMP server is also
Websocket server whereas this does not seems to be part of the WAMP
specification. What's your opinion about that?

Christophe

···

On Sat, Jan 19, 2013 at 11:18 AM, Tobias Oberstein <tobias.o...@gmail.com> wrote:

0 Likes

#4

Hi Christophe,

Hi Tobias,

Thanks for the quick answer.

We are designing a protocol requiring bi-directional RPC, each party
being RPC client and RPC server.

Are you designing a new protocol or extending WAMP?

We are designing an application-level protocol on top of WAMP.
Actually, I want to understand if the use I make of WAMP is compliant
to existing specs.

IMHO, there should not be a need to put a _protocol_ on top of WAMP. If your application use-case isn't fullfilled by WAMP, we should check if it makes sense to extend WAMP itself to cover the use-case. What is your use-case?

(...)

The transport can be anything providing a reliable, full-duplex, ordered
message channel.

If I understand correctly, using a single Websocket layer for two
symmetric WAMP connections is OK. Isn't it? There's no technical

No, having 2 WAMP sessions transported over 1 transport isn't covered by the spec, since that would require each and every WAMP message to contain a WAMP session ID.

Symmetric WAMP RPCs will be done over 1 WAMP session, running on 1 transport connection (= 1 WebSocket connection for now, and possible other transports later).

problems, I've a working implementation. But I'm wondering about the
WAMP compliancy.

(...)

To the best of my knowledge, there does not yet exist WAMP implementations
providing transports different from WebSocket.

Yes, and it seems there's all assuming the WAMP server is also
Websocket server whereas this does not seems to be part of the WAMP
specification. What's your opinion about that?

The spec explicitly mentions the independence on the underlying transport and the assumptions WAMP makes on the transport (reliable, full-duplex, ordered, message channel).

- Tobias

···

On Sat, Jan 19, 2013 at 11:18 AM, Tobias Oberstein > <tobias.o...@gmail.com> wrote:

Christophe

0 Likes

#5

IMHO, there should not be a need to put a _protocol_ on top of WAMP. If your
application use-case isn't fullfilled by WAMP, we should check if it makes
sense to extend WAMP itself to cover the use-case. What is your use-case?

This is a protocol between charging stations and a managing central
system. See http://www.ocppforum.net. We need symmetric RPCs. Current
implementations are SOAP-based, each peer being SOAP server and SOAP
client. Charging stations are most of the time connected through GPRS.

We plan to use WebSocket+WAMP instead of SOAP, trying to solve two
issues with current current SOAP layer:
- reduce verbosity (SOAP is way too verbose)
- provide a solution to have full communication even when charging
stations are behind a NAT router

(...)

No, having 2 WAMP sessions transported over 1 transport isn't covered by the
spec, since that would require each and every WAMP message to contain a WAMP
session ID.

Symmetric WAMP RPCs will be done over 1 WAMP session, running on 1 transport
connection (= 1 WebSocket connection for now, and possible other transports
later).

That means:
- using a single WebSocket connection each peer being at the same time
WAMP client and WAMP server is a non-compliant use of WAMP
- but using two WebSocket connections, each one being the carrier for
a WAMP connection, is compliant, even if we have
. one connection where WAMP server is WebSocket server, WAMP client is
WebSocket client
. another connection where WAMP server is WebSocket client, WAMP
client, is WebSocket server

Am I right?

Christophe

···

On Sat, Jan 19, 2013 at 4:46 PM, Tobias Oberstein <tobias.o...@gmail.com> wrote:

0 Likes

#6

IMHO, there should not be a need to put a _protocol_ on top of WAMP. If your
application use-case isn't fullfilled by WAMP, we should check if it makes
sense to extend WAMP itself to cover the use-case. What is your use-case?

This is a protocol between charging stations and a managing central
system. See http://www.ocppforum.net. We need symmetric RPCs. Current
implementations are SOAP-based, each peer being SOAP server and SOAP
client. Charging stations are most of the time connected through GPRS.

Interesting! Unfort., the

http://www.ocppforum.net/sites/default/files/ocpp%201%205%20-%20a%20functional%20description%20v2%200_0.pdf

spec seems to be somehow incomplete .. no mention of specific RPCs ..

We plan to use WebSocket+WAMP instead of SOAP, trying to solve two
issues with current current SOAP layer:
- reduce verbosity (SOAP is way too verbose)
- provide a solution to have full communication even when charging
stations are behind a NAT router

I see. Makes sense.

(...)

No, having 2 WAMP sessions transported over 1 transport isn't covered by the
spec, since that would require each and every WAMP message to contain a WAMP
session ID.

Symmetric WAMP RPCs will be done over 1 WAMP session, running on 1 transport
connection (= 1 WebSocket connection for now, and possible other transports
later).

That means:

Sorry if I haven't been clear enough.

For a precise discussion, please have a short look at

https://github.com/tavendo/wamp/issues/9

regarding definition of "roles" and terminology.

- using a single WebSocket connection each peer being at the same time
WAMP client and WAMP server is a non-compliant use of WAMP

Speaking of client/server only has meaning on the transport level. For WebSocket, a client is the peer that initiates the TCP connection. The server is the other peer.

With WAMP, there is only the following roles:

RPC: caller, callee
PubSub: publisher, subscriber, broker

Running 2 WAMP sessions over 1 transport instance is non-compliant.
Running 2 WAMP sessions over _different_ transport instances if compliant.

- but using two WebSocket connections, each one being the carrier for
a WAMP connection, is compliant, even if we have
. one connection where WAMP server is WebSocket server, WAMP client is
WebSocket client

Yes, if you speak of "WAMP caller" and "WAMP callee" instead of "WAMP client" and "WAMP server".

. another connection where WAMP server is WebSocket client, WAMP
client, is WebSocket server

Am I right?

WAMP needs a _transport_ to run over.

As said, WAMP itself makes only limited assumptions on the transport (reliable, ordered, full-duplex, message-based).

WAMP does not provide specifics how the transport is established.

Today, there are only WAMP implementations the implement a WebSocket binding for the transport.

With WebSocket, a client initiates the build-up of a transport: client establishes a TCP connection to a server and then does the WebSocket upgrade etc.

The fact that every WebSocket transport creation is initiated by the client results in NAT compatiblity.

However WAMP requires a 1:1 relation between WAMP sessions and transport instances.

You can of course have 2 WAMP sessions running over 2 different transport instances.

In case of running WAMP over WebSocket, both WebSocket connection are created by the same client to the same server.

···

Am 19.01.2013 16:59, schrieb GIR - Christophe Giaume:

On Sat, Jan 19, 2013 at 4:46 PM, Tobias Oberstein > <tobias.o...@gmail.com> wrote:

==

WAMPv2 will allow a peer of a single WAMP session to have 2 roles at the same time: "caller" and "callee".

In case of running WAMP over WebSocket, the client initiating the WebSocket connection will then play 2 roles on WAMP session-level: "caller" and "callee".

Today, with WAMPv1, that client could only play 1 role: "caller".

Same goes for server: today, only "callee". With WAMPv2, "callee" _and_ "caller".

===

In summary, I'd strongly discourage implementing "symmetric RPC" over 2 WebSocket transports.

WAMPv2 will allow you to do symmetric RPC over 1 WebSocket connection.

Of course, the "OCCP" and charging functionality is clearly "application level".

A WAMP binding of OCCP would merely need to specify RPC endpoints (URIs) and expected arguments/return values. Plus optionally any PubSub topics (URIs) with their payload.

Hope that helps,
Tobias

Christophe

0 Likes

#7

(...)

Interesting! Unfort., the
http://www.ocppforum.net/sites/default/files/ocpp%201%205%20-%20a%20functional%20description%20v2%200_0.pdf
spec seems to be somehow incomplete .. no mention of specific RPCs ..

RPCs are described in another document. You may need to register on
the web-site to get access to that technical spec.

(...)

Sorry if I haven't been clear enough.
For a precise discussion, please have a short look at
https://github.com/tavendo/wamp/issues/9
regarding definition of "roles" and terminology.

s/WAMP client/RPC caller/
s/WAMP server/RPC callee/
in my previous post :slight_smile:

(...)

Running 2 WAMP sessions over 1 transport instance is non-compliant.
Running 2 WAMP sessions over _different_ transport instances if compliant.

- but using two WebSocket connections, each one being the carrier for
a WAMP connection, is compliant, even if we have
. one connection where WAMP server is WebSocket server, WAMP client is
WebSocket client

Yes, if you speak of "WAMP caller" and "WAMP callee" instead of "WAMP
client" and "WAMP server".

OK, that means we've at least one possibility fitting our needs and
being compliant with current WAMP specs.

(...)

WAMPv2 will allow a peer of a single WAMP session to have 2 roles at the
same time: "caller" and "callee".

In case of running WAMP over WebSocket, the client initiating the WebSocket
connection will then play 2 roles on WAMP session-level: "caller" and
"callee".

Today, with WAMPv1, that client could only play 1 role: "caller".

Same goes for server: today, only "callee". With WAMPv2, "callee" _and_
"caller".

All we need is love^W WAMPv2.
WAMPv2 is all we need.

In summary, I'd strongly discourage implementing "symmetric RPC" over 2
WebSocket transports.

But that's the only solution with current spec.

WAMPv2 will allow you to do symmetric RPC over 1 WebSocket connection.

Is there already a WAMPv2 draft?
When is it supposed to land?

Of course, the "OCCP" and charging functionality is clearly "application
level".
A WAMP binding of OCCP would merely need to specify RPC endpoints (URIs) and
expected arguments/return values. Plus optionally any PubSub topics (URIs)
with their payload.

Agree.

Christophe

···

On Sat, Jan 19, 2013 at 5:45 PM, Tobias Oberstein <tobias.o...@gmail.com> wrote:

0 Likes

#8

In summary, I'd strongly discourage implementing "symmetric RPC" over 2
WebSocket transports.

But that's the only solution with current spec.

Correct .. but note that at least AutobahnPython

WAMPv2 will allow you to do symmetric RPC over 1 WebSocket connection.

Is there already a WAMPv2 draft?

Not yet .. still collecting/defining features. For WAMPv2, there will be a proper RFC.

When is it supposed to land?

We are already working on the symmetric RPC feature for AutobahnXXX. It will be one of the first features, since already a couple of people asked for it. This should land in the coming weeks.

Btw: which WAMP implementation are you using or planning to use in your system?

- Tobias

0 Likes