Reconnect TCPClient after interruption

Question

I have multiple instances of a client application, connecting to a main application over internet by TcpClient. (Both coded by me). So the connection is made like:

TcpClient.Connect(ip, port)

I now want this to handle various type of disconnect events:

1. Main App (server) or a client app computer lose internet connection.

   • On resume of connection, the communication seems lost, but when I try to reconnect, I get message: "A connection request was made on an already connected socket"
   • So I need to close and restart the client app.

2. Main App (server) is closed, and restarted.

   • Restarting the Main App, and then trying to reconnect the client app, results in same error as above.

So, what do I need to do? Do I need to instantiate a New TcpClient in the Client Apps, whenever such interruption occur? I haven't tried that, so don't know if that's a poor solution?

Solution 1

do I need to instantiate a New TcpClient in the Client Apps, whenever such interruption occur?

Yes. If the connection represented by the TcpClient is broken, you can't use that object for further communicating, nor can you connect it again. Create a new TcpClient object.

Your problem is likely that a NAT gateway times out your TCP connection, so nothing can get through between your server<->client, if all your client does is read from the connection, it will not discover this case, and it thinks the connection is still open.

Solution 2

I have typically solved this problem before in the past by using threads. I created a control thread that loops through and does administrative things like, check the connection, check the latest user input, check a server shutdown request, etc. When it is done it slept for half a second and did it all over again.

I then had a seperate Socket thread that was created and simply maintained a network socket. It would open the connection once started and loop repeatedly looking for incoming messages from whoever it was connected to. If it found a message it would process it and store it in a volatile object collection for consumption by the control thread. If something happened to the connection it would automatically try to resolve and if it couldn't it would go into a 'dead' state. The control thread at its next iteration would clean up the dead socket threads and create new ones as necessary.

Debugging was a nightmare but it was surprisingly stable once the bugs were worked out. On one instance it ran successfully for over a year with tens of thousands of connections and hundreds of concurrent connections with no need for restarts or any maintenance whatsoever.