Timeout on websockets

[Julien Genestoux]

Hello,

I'm creating a app that makes use of the great websockets API.

Since I'm doing this from my laptop, sometimes, it gets to sleep because the battery died, but I guess it would be the same with any other computer that saves ressouces by going into a "sleep" mode.

Once the computer wakes up, it seems that the websocket is still "connected" (readyState is still at 1), even though, obviously the socket wasn't maintained on the server... After a couple minutes (I wasn't able to measure how many, but it can be very long...), the webscoket connection eventually times out.

I wanted to know if there was a way to make this timeout shorter, or maybe probe the socket in any way?

Thanks,

Julien

[Takashi Toyoshima]

Hi, Julien.

Unfortunately, we could not use the readyState for checking reachability.
This is because the detection of unexpected disconnection is based on TCP.
It might be possible to close on machine's waking up explicitly, but
still there will
be many situations where you could not communicate with the server through
readyState is OPEN. CLOSED state and close event is useful only for
verification of graceful connection close.

To check reachability, you could implement heartbeats in your subprotocols.

The latest spec has a frame definition for ping and pong. It's not
clear now that
how these frames should be used. If this feature is exposed to JavaScript API,
you could use it for ping-pong outside of your subprotocols.

Also, you might be interested in following discussion.
http://code.google.com/p/chromium/issues/detail?id=76358 .

> --
> You received this message because you are subscribed to the Google Groups
> "Chromium HTML5" group.
> To post to this group, send email to chromiu...@chromium.org.
> To unsubscribe from this group, send email to
> chromium-html...@chromium.org.
> For more options, visit this group at
> http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
>

[PhistucK]

I suggest to add another readyState (or, well, more simply... state?) - "unreliable", which happens (after the connection was open) when there might be a connectivity problem. That will make the developer send a ping, wait for reviving, or alert the user that there might be a problem (with their internet connection, or with the connection to the server, or whatever).

Of course, the readyState should change to "open" when the connection is active again (the browser got some WebSocket connection feedback from the server).

Has something like this been suggested?

☆PhistucK

[Takashi Toyoshima]

Hi, PhistucK

You can discuss about API specification, here.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102
I mentioned similar idea as Comment 36.