Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different transports should be tuned for connection loss #46

Closed
plievone opened this issue Aug 23, 2012 · 2 comments
Closed

Different transports should be tuned for connection loss #46

plievone opened this issue Aug 23, 2012 · 2 comments

Comments

@plievone
Copy link
Contributor

Some experiments:

  1. XHR-polling, pull the cord: ping timeout in 60 secs. The good thing is that socket.send will error and disconnect immediately, so disconnect is easy to see when the user takes an action, or with a quick ping after a browser wakeup. Reconnecting seems easy, as the socket.open errored quickly when the network was down, so it could be repeated until success. (Haven't tried with proper network reachability issues but browser timeouts are usually reasonable.)
  2. JSONP, pull the cord: ping timeout in 60 secs. Unfortunately there are no errors coming from this transport. One will have to use custom RPC timeouts to detect that the connection is down. Also reconnecting is pain, as the socket.open does not give errors and hasn't got any timeouts, so it has to be opened with serial timeouts, clearing the last etc. Seems very easy to get stuck.
  3. WS, pull the cord: ping timeout in 60 secs. Surprisingly also here the transport is very quiet, and even socket.send seems to succeed (no errors, proper readystate, websocket.bufferedAmount stays at zero). I suspect that this 60 secs timeout will bite many, as things will seem unresponsive until timeout, disconnect and reconnect. WS transport is so lightweight and quick to establish, that quite quick heartbeats can be used, and a custom RPC call with a short timeout can be sent after browser wakeup etc. 60 secs ping timeout for websocket transport seems very bad, as reconnecting is so easy.

These are mostly application-level observations, but perhaps some transports could be tuned to ease the pain (I was very surprised by xhr vs. websockets)

@rauchg
Copy link
Contributor

rauchg commented Aug 24, 2012

Thanks @plievone for running this experiment.

What I would add to this is that the operating system in many cases is already taking care of probing the connection[1]… in which case we might want to leverage the offline event (provided the user agent implements it properly).

[1] I can't find the source for this right now but I remember reading about Microsoft's ping servers.

@rauchg
Copy link
Contributor

rauchg commented Aug 27, 2012

I'm closing this in favor of supporting offline event.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants