Disconnect/reconnect issue

[Frédéric NERET]

Hi All,

I have discovered an issue, very easy to reproduce. 

During a connection, just unplug your network cable, if you plug it again after more than 30/40 sec, your connection is down, and you have to refresh your page to reconnect.

Once you have these messages in the console, you are down:

GET http://demo.easyrtc.com/socket.io/1/?t=1373362942566  socket.io.js:2

GET http://demo.easyrtc.com/socket.io/1/?t=1373362943566  socket.io.js:2

GET http://demo.easyrtc.com/socket.io/1/?t=1373362945566  socket.io.js:2

Uncaught TypeError: Cannot read property 'sessionid' of undefined 

Or:

WebSocket connection to 'ws://demo.easyrtc.com/socket.io/1/websocket/iRBPnlmpuq0ZrTsag3JC' failed: WebSocket is closed before the connection is established. http://demo.easyrtc.com/socket.io/socket.io.js:2

Uncaught TypeError: Cannot read property 'sessionid' of undefined

In this case, you may have this message from easyrtc: Error Messages Miscellaneous error from signalling server. It may be ignorable.

FYI same issue with https://apprtc.appspot.com

This could be a real problem when you are in mobility...

Thanks,

Fred

[Rod Apeldoorn]

Howdy Fred and thanks for the report,

This is a problem which I put into one of our internal issue trackers awhile back but your post had Eric and I re-discussing the problem, some solutions, and possible problems with those solutions :)

For the current version, we can try and do better checking within the API to better detect a disconnect so it doesn't spawn the socket.io errors. Alas this just hides the real problem which is unfortunately not a simple one to solve.

The problem:

• Need better way to gracefully reconnect users after a socket connection has been interrupted.
• Sockets can be disconnected or unresponsive for multiple reasons.
• Computer issues: Power off / Sleep mode / Browser crash
• Cable breaks
  
• Network / provider issues
• Switching from wired to wifi
• Switching wifi stations
• Switching cell networks
• I haven't done a drive test to see what happens when I switch towers

Considerations and challenges:

• Detecting disconnections:
• We currently rely on socket.io disconnection detection. Is there a better way?
• Should we adjust the 60 second timeout?
• note: In next major release we'll be offloading much of the socket.io and http app configuration to the end user.
• Reconnecting before 60 second timeout:
• This usually works if person remains on the same network + interface.
• If automatic socket.io reconnection fails. We should attempt to reconnect.
• This would usually involve getting a new easyrtcid. Can/should we maintain the old easyrtcid?
• Associating the old and new connections could present security issues.
• Associating the old and new connections could present programming issues.
• We can immediately send an 'ack' to the old connection with a shorter timeout (1 or 2 seconds). If there is no response we can consider the old connection gone.
• If a new connection is made before timeout, it could mean two visible connections.
  
• We can hold on accepting the new connection until the old has been verified as being disconnected.
• For many security conscious apps, a re-authentication is a requirement. This should hopefully be doable automatically.
• note: in the next major release we plan a customizable authentication method
• We should test other socket.io transports. In some situations using websockets may not be robust enough.
• Socket.io supports the following transports: websocket, htmlfile, xhr-polling, jsonp-polling
• Current WebRTC connections can fail or regain connection independent of easyRTC.
• We already try to detect when these connections continue
• Do we maintain, restart, or end WebRTC connections after successful easyRTC server reconnection?
  
• This could mean telling the other client of this, thus adding complication to their code.
• We may end up defaulting to ending the connection, but providing method for client code to override this.
• Do we maintain, restart, or end WebRTC connections if they continue after a disconnect has been identified with no reconnection?
• Currently they will end. It is too confusing for the app otherwise.

I agree that greater robustness of connections is a necessity going forward. Any comments or recommendations anyone has now could shape the direction we take.

-Rod Apeldoorn, Priologic Software

Edits: I changed the 30 second default timeout to the proper 60 seconds.

[Frédéric NERET]

Really, this issue is not esasy to solve, and your analysis is very detailed.

I think the timeout to 60sec is good enough, however this kind of issue is not very common but it's a good thing to keep it in mind.

Best regards,

Fred

[Suresh Kumar]

Is this issues got resolved? Since it is posted long back. 

We are still getting below error message often. This happens only when we try to connect from two different machines. 

Error messages

Miscellaneous error from signalling server. It may be ignorable.

WebSocket connection to 'wss://10.87.151.43:8443/socket.io/1/websocket/aUJb3WuBNsUXsGgfiuMN' failed: Error in connection establishment: net::ERR_TIMED_OUT

[Eric Davies]

Seems to be a problem I can repeat. I'll look into this weekend.