0

This question talks about how it can be non-trivial to detect whether a TCP connection has disconnected: Detecting TCP Client Disconnect

What it doesn't answer is, do I need to detect such cases if I'm using modern asynchronous .NET networking classes? If my server accepts incoming connection requests from clients, and clients are responsible for re-connecting if they detect a problem, is it an issue? For instance if Client A periodically reconnects will its former connection get tidied up behind the scenes? If clients are badly behaved and disconnect improperly - which is not entirely under my control - can I end up with a load of 'stale' connections impacting performance?

I am not sure if any of this is .NET specific, or just generic TCP/IP.

Mr. Boy
  • 60,845
  • 93
  • 320
  • 589

1 Answers1

1

I think, this depends on some details. E.g. are TCP sockets created with the TCP_KEEPALIVE flag enabled (can be seen with strace -e network ... in Linux)? Or are you writing to them regularly?

If the answer to both is "no", you may end up with stale connections and those can not only cause performance issues, but there are also limits to how many you can have at a time (1024 by default in Linux). So if enough stale connections accumulate, your service could become unresponsive.

Bernhard M.
  • 186
  • 4
  • Well you are testing my TCP knowledge now! I'm not aware of that flag but in my particular case, connections are used for 2 way communication and I believe are expected to be permanent for a session between client and server – Mr. Boy Oct 29 '19 at 15:51