1

I have a Node.js net socket server running which works fine with a low number of clients connected to it. When I up the number to 200 client connections though, all of the initial connections establish and communicate correctly but when I hit Ctrl-C to close the client program only some of the disconnects are received on the server (via the Error: read ECONNRESET message).

I am listening to the events: close, timeout, disconnect, error and end I also check if the data event receives a length 0 data, but this situation is never triggered.

The error/disconnect events just appear to not trigger sometimes when there are a lot of disconnects at the same time.

The server and client receives no exceptions or errors while running; both are Node.js.

netstat -i shows that all connections are terminated on the client

lsof -i shows many connections still established on the server

(example of connection left open on the server from lsof)

node 5569 root 18u IPv4 4236971 0t0 TCP xxx.xxx.xxx.xxx:2048->xxxxxx.hsd1.ca.comcast.net:12501 (ESTABLISHED)

Has anyone else run across this?

Will Perone
  • 21
  • 5

2 Answers2

1

You should consider incorporating some sort of special ping/keepalive message that both the client and server send periodically to more accurately/quickly check for dead sockets on both ends.

mscdex
  • 104,356
  • 15
  • 192
  • 153
  • This is something I have considered though ideally I would like to keep socket traffic down as much as possible as there will then be keepalives from thousands of clients. I would put something like this in but it feels like it's not really solving the root issue. Interestingly enough, Node.js [supports this natively](http://nodejs.org/api/net.html#net_socket_setkeepalive_enable_initialdelay) I wonder if it's because they already knew of this issue. – Will Perone Sep 11 '14 at 15:54
  • There is `setKeepAlive()`, but [it may not do what you expect it to do](http://stackoverflow.com/questions/18614176/why-nodejs-keepalive-does-not-seem-to-work-as-expected). IMHO application-level keepalive messages are better because you have greater control over it. As long as you're not sending them too frequently, I wouldn't worry about the keepalive traffic. – mscdex Sep 11 '14 at 16:08
  • Yea reading more on [how TCP works internally](http://www.pcvr.nl/tcpip/tcp_conn.htm) the client has to send a FIN packet for the server to process the socket as closed unless there is a keepalive/timeout on the socket. This makes sense considering underneath a TCP socket it's like UDP. It looks like an application level keepalive is the only consistent way to do this then. – Will Perone Sep 11 '14 at 16:55
  • Thanks by the way, I would upvote you but I don't yet have enough reputation to do so. – Will Perone Sep 11 '14 at 17:11
1

It appears that ECONNRESET is only triggered when the connection closes while there is data being written/read on the socket. If the socket closes when there is no traffic on it AND the client does not send a FIN packet to the server (as in the client has crashed or abruptly closed the connection) AND there is no timeout/keepalive on the socket, then the other side never knows that the connection has been terminated until it tries to send something on the socket again and realizes that the connection is broken.

Will Perone
  • 21
  • 5
  • Yep, the `timeout` is fixed on 120sec. But you can do a `response.end` to send the `FIN`. Plus: http://stackoverflow.com/questions/21953784/how-to-send-the-fin-with-node-js. Greetings!! – loveNoHate Sep 11 '14 at 17:27
  • I believe there is no timeout by default on the sockets in Node.js: http://nodejs.org/api/net.html#net_socket_settimeout_timeout_callback – Will Perone Sep 11 '14 at 17:42