PING and PONG message type

#1

Yes.

FWIW, I now implemented automatic ping/pongs in AutobahnPython (both client and server) - WebSocket based for now:

https://github.com/tavendo/AutobahnPython/blob/autopingpong/examples/twisted/websocket/pingpong_keepalive/server.py

That works: detects broken connections even when you simply "pull the plug".

This is obviously only working for WebSocket transports.

We'll expose that in Crossbar.io soon

http://crossbar.io/docs/WebSocket-Options/
https://github.com/crossbario/crossbar/issues/105

···

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 timeout.
And then send the meta event.

==

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

0 Likes

#2

Hi Matt,

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

···

Am 27.08.2014 00:00, schrieb Matt Bonneau:

Regards,
Matt

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
    timeout.
     > And then send the meta event.

    Yes.

    FWIW, I now implemented automatic ping/pongs in AutobahnPython (both
    client and server) - WebSocket based for now:

    https://github.com/tavendo/AutobahnPython/blob/autopingpong/examples/twisted/websocket/pingpong_keepalive/server.py
    <https://github.com/tavendo/AutobahnPython/blob/autopingpong/examples/twisted/websocket/pingpong_keepalive/server.py>

    That works: detects broken connections even when you simply "pull
    the plug".

    This is obviously only working for WebSocket transports.

    We'll expose that in Crossbar.io soon

    http://crossbar.io/docs/WebSocket-Options/
    <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>.
To post to this group, send email to wam...@googlegroups.com
<mailto:wam...@googlegroups.com>.
Visit this group at http://groups.google.com/group/wampws.
To view this discussion on the web visit
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>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#3

for me the callback of "wamp.metaevent.session.on_leave" gets called in
notime if i unplug a module. *Perfect!*

I'd say hooray, but I'm not so sure=( The problematic cases are these:

- WAMP component is connected to router over a WAN connection - which breaks or just becomes unresponsive

- WAMP component is connected to router over LAN connection - and you hard kill the component (not just CTRL-C it .. which will likely close the TCP orderly) or plug the cable

Fast detection of transport (and hence WAMP session) loss in above cases is a concern ..

The only thing I really miss is some information about the "dead-buddy".
In the callback i get an empty object and the regular details (where
"publisher" is "undefined" by default).

Looking to session.py [339]:

    msg = message.Publish(0, u'wamp.metaevent.session.on_leave',
    [self._session_details])
    self._router.process(self, msg)

It seems to me the "session_details".are getting lost somewhere on the
way...

Oh. That might be the case: self._session_details being deleted before the event gets sent.

If so, this is a bug. Could you pls file it on CB repo?

···

Am 26.08.2014 14:31, schrieb 42o8o1oo:

--
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>.
To post to this group, send email to wam...@googlegroups.com
<mailto:wam...@googlegroups.com>.
Visit this group at http://groups.google.com/group/wampws.
To view this discussion on the web visit
https://groups.google.com/d/msgid/wampws/7e9f08c9-44bd-4dcc-a2c3-bbc4b112293f%40googlegroups.com
<https://groups.google.com/d/msgid/wampws/7e9f08c9-44bd-4dcc-a2c3-bbc4b112293f%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#4

Hi Matt,

> I did mean point-to-point. The messages are just between the router and

the client.

Ah. Ok.

The ping and pong WAMP messages would serve almost the same function as
the websocket ping and pong, except it brings it up to the next protocol
level and verifies that the client (or router) is still processing and
responding to WAMP messages.

This would give us a universal method that would work regardless of
transport (PING/PONG message types).

The only transport defined in WAMP BP is WebSocket. Which does have ping/pong already.

So we are talking about RawSocket and LongPoll transports (or possible future ones), right?

Both of these are WAMP AP - hence anything we come up with would reside there.

Regarding your proposal:

[PING, Request|id, Options|dict, Echo|list, Discard|string]
[PONG, PING.Request|id, Details|dict, Echo|list]

Why is Echo a list, and not a string?

Cheers,
/Tobias

···

Regards,
Matt

On Wednesday, August 27, 2014 9:24:07 AM UTC-4, Tobias Oberstein wrote:

    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

     >
     > Regards,
     > Matt
     >
     > 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
     > timeout.
     > > And then send the meta event.
     >
     > Yes.
     >
     > FWIW, I now implemented automatic ping/pongs in
    AutobahnPython (both
     > client and server) - WebSocket based for now:
     >
    https://github.com/tavendo/AutobahnPython/blob/autopingpong/examples/twisted/websocket/pingpong_keepalive/server.py
    <https://github.com/tavendo/AutobahnPython/blob/autopingpong/examples/twisted/websocket/pingpong_keepalive/server.py>

     >
    <https://github.com/tavendo/AutobahnPython/blob/autopingpong/examples/twisted/websocket/pingpong_keepalive/server.py
    <https://github.com/tavendo/AutobahnPython/blob/autopingpong/examples/twisted/websocket/pingpong_keepalive/server.py>>

     >
     > That works: detects broken connections even when you simply
    "pull
     > the plug".
     >
     > This is obviously only working for WebSocket transports.
     >
     > We'll expose that in Crossbar.io soon
     >
     > http://crossbar.io/docs/WebSocket-Options/
    <http://crossbar.io/docs/WebSocket-Options/>
     > <http://crossbar.io/docs/WebSocket-Options/
    <http://crossbar.io/docs/WebSocket-Options/>>
     > https://github.com/crossbario/crossbar/issues/105
    <https://github.com/crossbario/crossbar/issues/105>
     > <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...@googlegroups.com <javascript:>
     > <mailto:wampws...@googlegroups.com <javascript:>>.
     > To post to this group, send email to wam...@googlegroups.com
    <javascript:>
     > <mailto:wam...@googlegroups.com <javascript:>>.
     > Visit this group at http://groups.google.com/group/wampws
    <http://groups.google.com/group/wampws>.
     > To view this discussion on the web visit
     >
    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>

     >
    <https://groups.google.com/d/msgid/wampws/daf1d36d-d3a7-408f-a093-feaeafc05f63%40googlegroups.com?utm_medium=email&utm_source=footer
    <https://groups.google.com/d/msgid/wampws/daf1d36d-d3a7-408f-a093-feaeafc05f63%40googlegroups.com?utm_medium=email&utm_source=footer>>.

     > For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>.

--
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>.
To post to this group, send email to wam...@googlegroups.com
<mailto:wam...@googlegroups.com>.
Visit this group at http://groups.google.com/group/wampws.
To view this discussion on the web visit
https://groups.google.com/d/msgid/wampws/f160a776-6ee6-44ff-851a-bc122852c32c%40googlegroups.com
<https://groups.google.com/d/msgid/wampws/f160a776-6ee6-44ff-851a-bc122852c32c%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#5

Hi Matt,

I do think adding the PING and PONG messages to the advanced profile is
a good idea.

https://github.com/tavendo/WAMP/issues/90

Cheers,
/Tobias

0 Likes

#6

Hi Matt,

I do think adding the PING and PONG messages to the advanced profile is
a good idea.

After the discussions on #63 and #90, I now think it's wrong to add a transport level feature like loss detection / keep alive at the WAMP level.

For RawSocket, here is a proposal to add ping/pong at transport level

https://github.com/tavendo/WAMP/issues/63#issuecomment-53856688

With above, we have transport loss detection / keep alive for WebSocket and RawSocket. For Long-poll, it needs to be done differently anyway: by adjusting the poll timeout. And I won't think about yet to be invented transports for now. The former 3 already cover a lot. E.g. stuff like function-call based transports or shared-memory queues don't need ping/pong anyway.

I would like to push #63 and #90 to an end now so we can move on to other features in WAMP AP - there are plenty which need more love.

What do you think? Would you be fine with RawSocket transport-level ping/pong and closing #90?

Cheers,
/Tobias

0 Likes