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
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
Symmetric WAMP RPCs will be done over 1 WAMP session, running on 1 transport
connection (= 1 WebSocket connection for now, and possible other transports
Sorry if I haven't been clear enough.
For a precise discussion, please have a short look at
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
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,