You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
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.
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)
The text was updated successfully, but these errors were encountered:
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.
Some experiments:
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)
The text was updated successfully, but these errors were encountered: