Subject: [hybi] Ping frame from WS clients (more a WS API question)

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 12 Sep 2011 11:15:29 +0200

Hi, WebSocket API does not define how the client (web-browser of
course) can send a Ping frame. Even more, it's not defined at all:

  http://dev.w3.org/html5/websockets/#the-websocket-interface

Sometimes the Internet connection is gone and the client has not
realized that the TCP connection is dead (it does not realize of it
until it tries to send data over the connetion). So, in this case, the
client has no way to realize that the TCP connection (or the WS
connection) is unavailable. The only way would be defining a "ping" at
WS subprotocol level, which would be ugly having Ping/Pong frames
already defined in WS transport protocol.

So, IMHO the WS API should include a mechanism for the client to send
WS ping to the server periodically. Do you agree?

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 12 Sep 2011 11:31:14 +0200

2011/9/12 Dirkjan Ochtman <[email-masked]>:
> Isn't the WS interface discussed on another mailing list than this
> one, at the W3C?

Taking into account that I already recognized that in my mail
subject... the answer is "yes".
I just wanted to know the opinion of the WG about this.

> No, it seems to me the low-level user agent/client would be
> responsible for things like this, instead of the API user.

IMHO the API user could, at least, "configure" an interval for WS
connection monitoring, so:

 var myWS = new WebSocket("ws://some-domain-with-dns-A-resolution.com");
 myWS.monitor_interval(120);

In this way, the API user instructs the WebSocket client to send a
Ping frame every 120 seconds. In case a Pong is not received within N
seconds (to define) the WS socket state would become "DISCONNECTED" or
"DISCONNECTING".

I've reported it in W3C:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14115

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Philipp Serafin <[email-masked]>
Date: Mon, 12 Sep 2011 11:42:19 +0200

I agree that web authors should not be required to deal with pings. My guess
is that 40% of web developers would just implement something like

setInterval(function() {
 myWSConn.sendPing();
}, 30000);

Which can cause lots of unnecessary packets.

Another 40% wouldn't realize they need to ping at all and would be
dumbfounded when their connection dies unexpectedly.

On the other hand, the browser can implement pinging a lot more efficiently
than web apps ever could, because it has direct access to the underlying
socket API and can keep track of latency and timeout information much
better.

A way for application authors to specify timeouts sounds reasoneable. But
this is just as relevant to non-browser clients than it is to browsers/web
apps. This should be built into the protocol (maybe as another handshake
header) and not the JS api, so all kinds of WS clients can make use of it.

On Mon, Sep 12, 2011 at 11:31 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Philipp Serafin <[email-masked]>
Date: Mon, 12 Sep 2011 11:51:41 +0200

... also, if there are guarantees that the server does periodical pings
(and the server's ping frequency is known), why would the client need to
ping at all? It could just declare the connection as "dead", once it didn't
receive any data from the server within <server ping interval> + <some
constant> units of time.

>
> On Mon, Sep 12, 2011 at 11:31 AM, Iñaki Baz Castillo <[email-masked]>wrote:
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 12 Sep 2011 18:52:07 +0900

> Mozilla's Aurora is trying to utilize it by implementing automatic ping
running in background. Which is now configurable via about:config. Exposing
API for enable/disable such auto ping and configuring period/timeout is one
of possible options.

Method to ping manually might be also useful, but I don't have ideas for
now.

> seconds (to define) the WS socket state would become "DISCONNECTED" or

If there's some big frame transferred s->c, the server cannot insert Pong.
Fragment doesn't help here. So, I'd not close the socket because of not
receiving response Pong in N sec, but when s->c is idle for some specified
timeout N sec after sending Ping. (I'd not take into account the effect of
RTT.)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 12 Sep 2011 21:11:22 +0200

> seconds (to define) the WS socket state would become "DISCONNECTED" or

If people here agree with the proposal above for the WS API, please
comment it in the WS API tracker:

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=13104

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>