Hi Matt,
Am 27.08.2014 00:00, schrieb Matt Bonneau:
> Hi Tobias,
>
> 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
> functionality.
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.
Concrete:
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;)
/Tobias
> <
http://crossbar.io/docs/WebSocket-Options/>
>
https://github.com/crossbario/crossbar/issues/105
> <
https://github.com/crossbario/crossbar/issues/105>
>
> ==
>
> 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 ..
>
> Cheers,
> /Tobias
>
>
> >
> > Cheers,
> > Bas
> >
>
> --
> 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
> <mailto:
wampws+un...@googlegroups.com>.
> <mailto:
wam...@googlegroups.com>.
>
https://groups.google.com/d/msgid/wampws/daf1d36d-d3a7-408f-a093-feaeafc05f63%40googlegroups.com
> <
https://groups.google.com/d/msgid/wampws/daf1d36d-d3a7-408f-a093-feaeafc05f63%40googlegroups.com?utm_medium=email&utm_source=footer>.