I would still like to see PING and PONG added to the basic profile:
Ping is sent from Client to Router or Router to Client to test the
connection end-to-end and to verify that the other end is handling messages
What do you mean with "end-to-end"?
The transport between a WAMP client and a WAMP router is "point-to-point".
In case of a WAMP caller calling a WAMP callee, there are 2 legs:
C1 <-- leg 1 --> R <-- leg 2 --> C2
Both leg1 and leg2 can be kept alive / fast connection loss detection using WebSocket pings/pongs when using WebSocket transport.
This only works on WebSocket (since it has it's own transport-level facilities for that).
It does not work on RawSocket. Is that what you are concerned about?
There is no mechanism for C1 sending a WAMP level Ping thing that crosses the router and is replied by C2.
That would introduce a coupling between C1 and C2. C1 isn't (and shouldn't) be aware that a call it issues is handled by C2.
All parameters after request id can be omitted
[PING, Request|id, Options|dict, Echo|list, Discard|string]
PONG must be sent upon receive a ping request. Echo is sent back to the peer that requested.
[PONG, PING.Request|id, Details|dict, Echo|list]
A possible usage scenario:
Suppose you have an important RPC call that you need to have high
availability. If the callee's session becomes unresponsive for any
reason, it will not able to reconnect and reregister until the first
(and now hung) client session is removed.
I would like to build an option into the register handler to request
that the server "PING" the client that currently is holding the
registration. If that times out, then proceed with destroying the
non-responsive session and go ahead and register the latter registration
request. If the server receives a timely PONG message, it can reject the
latter registration attempt.
This would require the full stack to be responsive, not just the
transport (as with TCP keepalive or Websocket ping/pong). This would
also allow transports that don't have keepalive support to have the ping
I have re-read what you wrote a couple of times. I don't get what you mean.
Let's make it more concrete.
Say Callee1 has registered "com.myapp.add2".
Now Callee1 transport becomes unresponsive. This can be detected on WebSocket using WebSocket pings/pongs (let's continue the example with that transport only for now).
When the Router recognizes that the transport for Callee1 is broken, it'll kick the WAMP session, and unregister "com.myapp.add2" automatically.
At that point, another session can register "com.myapp.add2".
Above introduces a "time gap" in which no one (reachable) has "com.myapp.add2" registered.
Are you concerned about this gap?
If so, my thinking would probably start in more in this direction:
Automatic callee failover to a "hot-standby" callee.
Callee1 has registered "com.myapp.add2".
Now Callee2 (a different WAMP session) registered _also_ "com.myapp.add2" providing the option "hot_standby = true" or something.
The router allows this, since it is a hot standby callee. Normally it would reject registering a 2nd callee for the _same_ URI.
If the router now processes a call to "com.myapp.add2" that fails because the transport got unresponsive, or the call doesn't return at all within a given timeout, it'll failover "com.myapp.add2" to Callee2.
This could happen completely transparently with regard to the caller.
This is of course a highly advanced feature: definitely WAMP AP.
Not sure -- let me know if I misunderstood you / I now got wild;)
Am 27.08.2014 00:00, schrieb Matt Bonneau:
On Sunday, August 10, 2014 8:06:02 AM UTC-4, Tobias Oberstein wrote:
Am 10.08.2014 06:54, schrieb Bas Wegh:
> Would be great in combination with The Ping and pong message type.
> So the router can check the connections and kill the session on
> And then send the meta event.
FWIW, I now implemented automatic ping/pongs in AutobahnPython (both
client and server) - WebSocket based for now:
That works: detects broken connections even when you simply "pull
This is obviously only working for WebSocket transports.
We'll expose that in Crossbar.io soon
I need to contact the Twisted/asyncio guys, since I am concerned about
scalability of having massive numbers of timers.
Until then, it's on above branch ..
You received this message because you are subscribed to the Google
Groups "WAMP" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to wampws+un...@googlegroups.com
To post to this group, send email to wam...@googlegroups.com
Visit this group at http://groups.google.com/group/wampws.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.