10

I have a production app that uses socket.io (node.js back-end)to distribute messages to all the logged in clients. Many of my users are experiencing disconnections from the socket.io server. The normal use case for a client is to keep the web app open the entire working day. Most of the time on the app in a work day time is spent idle, but the app is still open - until the socket.io connection is lost and then the app kicks them out.

Is there any way I can make the connection more reliable so my users are not constantly losing their connection to the socket.io server?

EToreo
  • 2,936
  • 4
  • 30
  • 36
  • What kind of computers are the clients using? Mobile devices? Tablets? Laptops? Desktops? Many devices these days will go into power save modes when the device has not been active and that will cause connections to get shut down. – jfriend00 May 16 '15 at 20:58
  • 100% desktops, mostly modern browsers IE 9 or greater (for the most part), Chrome and Fire Fox. The connection issues don't seem to be on any particular browser. – EToreo May 17 '15 at 00:58
  • Do any of the desktops have a sleep mode where the CPU goes to sleep? – jfriend00 May 17 '15 at 01:16
  • I wish I knew for sure, but I honestly doubt it. I have reproduced it on a computer without a sleep mode (OS or CPU). – EToreo May 17 '15 at 01:19
  • If it isn't the local computer killing the connection and it isn't the server, then it must be some piece of network infrastructure in the path between client and server. If socket.io is configured correctly and the client doesn't sleep, it should reconnect when the connection drops. – jfriend00 May 17 '15 at 01:22
  • These are exactly my thoughts, and I am having trouble coming up with an idea on how to fix it or even debug it... – EToreo May 17 '15 at 01:46

2 Answers2

8

It appears that all we can do here is give you some debugging advice so that you might learn more about what is causing the problem. So, here's a list of things to look into.

  1. Make sure that socket.io is configured for automatic reconnect. In the latest versions of socket.io, auto-reconnect defaults to on, but you may need to verify that no piece of code is turning it off.

  2. Make sure the client is not going to sleep such that all network connections will become inactive get disconnected.

  3. In a working client (before it has disconnected), use the Chrome debugger, Network tab, webSockets sub-tab to verify that you can see regular ping messages going between client and server. You will have to open the debug window, get to the network tab and then refresh your web page with that debug window open to start to see the network activity. You should see a funky looking URL that has ?EIO=3&transport=websocket&sid=xxxxxxxxxxxx in it. Click on that. Then click on the "Frames" sub-tag. At that point, you can watch individual websocket packets being sent. You should see tiny packets with length 1 every once in a while (these are the ping and pong keep-alive packets). There's a sample screen shot below that shows what you're looking for. If you aren't seeing these keep-alive packets, then you need to resolve why they aren't there (likely some socket.io configuration or version issue).

  4. Since you mentioned that you can reproduce the situation, one thing you want to know is how is the socket getting closed (client-end initiated or server-end initiated). One way to gather info on this is to install a network analyzer on your client so you can literally watch every packet that goes over the network to/from your client. There are many different analyzers and many are free. I personally have used Fiddler, but I regularly hear people talking about WireShark. What you want to see is exactly what happens on the network when the client loses its connection. Does the client decide to send a close socket packet? Does the client receive a close socket packet from someone? What happens on the network at the time the connection is lost.

webSocket network view in Chrome Debugger

webSocket network view in Chrome Debugger

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • hi, after socket disconnects by itself, my code stops working until i refresh the app. – kd12345 Oct 20 '22 at 09:31
  • @kd12345 - Plain webSockets have no auto-reconnection logic, so if you want recconect features, you have to build it yourself or use socket.io which has auto-reconnection logic built on top of webSocket. – jfriend00 Oct 20 '22 at 21:43
  • I am actually using socket.io, but for some reason the socket breaks my nodejs server when it disconnects https://stackoverflow.com/questions/74121600/app-stops-working-when-i-keep-sending-multiple-messages-with-socket-io/ – kd12345 Oct 23 '22 at 08:16
1

The most likely cause is one end closing a WebSocket due to inactivity. This is commonly done by load balancers, but there may be other culprits. The fix for this is to simply send a message every so often (I use 30 seconds, but depending on the issue you may be able to go higher) to every client. This will prevent it from appearing to be inactive and thus getting closed.

Aaron Dufour
  • 17,288
  • 1
  • 47
  • 69
  • 6
    socket.io already does automatic heartbeat messages to both keep the connection open and to detect when it's been broken. So, there is no need to send your own messages. There appears to be something else (other than inactivity) that is causing the connection to get shut-down. – jfriend00 May 16 '15 at 20:56
  • @jfriend00 i tried yours but my socket io goes to ping time out after 30 seconds of when the page is not in foucs on mobile browsers, i even changed the socket io timeout settings, but it didnt make any difference, i even tried emitting my own heartbeat event, but still it timeout after 30 sec, following your suggestion i did this, but socket io still timesout when page is not in foucs, please check if u can help https://stackoverflow.com/questions/58667207/prevent-socket-io-from-ping-timeout-on-inactive-or-not-focused-browser-page-on-c – Faizan Nov 02 '19 at 00:31
  • 1
    @Faizan - I don't know why you're responding on this other answer. Mobile browsers may shut-down pages that aren't in the foreground to save battery. There's likely nothing you can do about it to keep a webSocket alive in a mobile browser. – jfriend00 Nov 02 '19 at 00:38