3

I created a game using node.js and socket.io. All works well, but from time to time this game socket server doesn't respond to any connections. When I go to Process information -> Files and connections (in webmin), then I see there are many connections with CLOSE_WAIT and FIN_WAIT2 statuses. I think the problem is in these connections, because game fails when there are about 1,000 connections. Server OS is Ubuntu Linux 12.04.

How can I kill these connections or increase maximum allowed connections?

Tass
  • 1,628
  • 16
  • 28
Armīns Nikolajevs
  • 99
  • 3
  • 8
  • I run application for 1 hour, and there ir 8 "FIN_WAIT2" connections and all from same IP address. There played about 50 different players, but only 1 player connections stay in this status. Maybe someone has encountered such a problem? Maybe I need to change some socket.io settings (server and client side, at this time I use default settings)? – Armīns Nikolajevs Mar 28 '13 at 12:08

3 Answers3

1

To add to Jim answer, i think there is a problem in your client handling of closing of socket connections . It seems your client is not closing the sockets properly(both server initiated and client initiated close) and that is the reason your server has so many wait states

Pradheep
  • 3,553
  • 1
  • 27
  • 35
  • 1
    This is not an answer; it should be a comment to the answer it refers to – Jim Garrison Mar 25 '13 at 19:52
  • The problem is in the application and as long as its not fixed it will not solve the problem. This us a valid answer as it points to the root cause. – Pradheep Mar 26 '13 at 16:58
1

You don't need to kill connections or increase the number allowed. You need to fix a defect in the application on one side of the connection, specifically, the side which does not initiate the close.

See Figure 13 of RFC 793. Your programs are at step 3 of the close sequence. The side which you see in FIN-WAIT-2 is behaving correctly. It has initiated the close and the TCP stack has sent a FIN packet on the network. The side in CLOSE-WAIT has the defect. The TCP stack on that side has received and acknowledged the FIN packet, but the application has failed to notice. How the application is expected to detect that the remote side has closed the connection will depend on your platform. Unfortunately, I am old, and don't know node.js or socket.io.

What happens in C is that the socket appears readable, but a read() returns a zero-length packet. When the application sees this, it is expected to call close(). You will find something equivalent in the docs for node.js or socket.io.

When you find it, considering answering your own question here and accepting the answer.

fizzer
  • 13,551
  • 9
  • 39
  • 61
  • Most of the time this socket is managed in a lower level library, which the developer did not write. For example, Tomcat. I haven't tried yet, but a solution like this might help https://stackoverflow.com/a/61139251/1620112 – Charlie Dalsass Jan 07 '23 at 20:57
0

Linux has the SO_REUSEADDR option for setting socket parameters. It allows immediate reuse of the same port. Someone who knows your toolset can tell you how to set socket options. You may already know how. I do not know this toolset.

From older java docset: http://docs.oracle.com/javase/1.5.0/docs/guide/net/socketOpt.html

Uli Köhler
  • 13,012
  • 16
  • 70
  • 120
jim mcnamara
  • 16,005
  • 2
  • 34
  • 51
  • To add to Jim answer, i think there is a problem in your client handling of closing of socket connections . It seems your client is not closing the sockets properly(both server initiated and client initiated close) and that is the reason your server has so many wait states – Pradheep Mar 25 '13 at 20:27
  • Missing SO_REUSEADDR would manifest itself as a failure to bind. OP has got further than this. – fizzer Mar 26 '13 at 08:04