Reset TCP connection if server closes/crashes mid connection

Question

I have a tcp connection like follows:

    public void ConnectToServer()
    {
        string mac = GetUID();


     while(true)
     {

        try
        {
             tcpClient = new TcpClient("xx.x.xx.xxx", xxxx);
             networkstream = new SslStream(tcpClient.GetStream());

                networkstream.AuthenticateAsClient("xx.x.xx.xxx");


                networkstream.Write(Encoding.UTF8.GetBytes("0002:" + mac + "\r\n"));
                networkstream.Flush();



                    string serverMessage = ReadMessage(networkstream);
                    Console.WriteLine("MESSAGE FROM SERVER: " + serverMessage);



            }
            catch (Exception e)
            {
                tcpClient.GetStream().Close();
                tcpClient.Close();


            }
    }
    }

This works fine and can send a receive data to/from the server.

What I need help with, if the server isn't running when the client starts, it'll wait and then connect once the server is up. But, if both the client and server are running and everything is working, if I close the server, the client will not reconnect(because I don't have anything to handle the event yet).

I have seen some answers on here that suggest polling and such. Is that the only way? The ReadMessage method that I call get into an infinite loop as well. I can post that code if need be.

I would really like to detect when the server closes/crashes and close the stream and the tcpclient and reconnect ASAP.

Here is my readmessage:

static string ReadMessage(SslStream sslStream)
    {

        if (sslStream.CanRead)
        {
            byte[] buffer = new byte[2048];
            StringBuilder messageData = new StringBuilder();
            int bytes = -1;
            string message_type = null;
            string actual_message = null;
            do
            {
                try
                {
                    Console.WriteLine("LENGTH: " + buffer.Length);
                    bytes = sslStream.Read(buffer, 0, buffer.Length);




                    Decoder decoder = Encoding.UTF8.GetDecoder();
                    char[] chars = new char[decoder.GetCharCount(buffer, 0, bytes)];
                    decoder.GetChars(buffer, 0, bytes, chars, 0);
                    messageData.Append(chars);

                    message_type = messageData.ToString().Substring(0, 5);
                    actual_message = messageData.ToString().Substring(5);
                    if (message_type.Equals("0001:"))
                    {
                        m_Window pop = new m_Window();
                        pop.callHttpPost(null, new EventArgs());

                    }
                    if (messageData.ToString().IndexOf("\r\n") != -1)
                    {
                        break;
                    }
                }
                catch (Exception e)
                {
                    Console.WriteLine("ERROR: " + e.Message);

                }
            } while (bytes != 0);
            return messageData.ToString();
        }
        return("CONNECTION HAS BEEN LOST");

    }

Answer 1

With TCP you have 2 kinds of a server disconnect:

• the server is closed
• the server crashes

When the server is closed, you are going to receive 0 bytes on your client socket, this is the way you know that the peer has closed its end of the socket, which is called a half close. But thing get more ugly if the server crashes. When that happens again you have several possibilities. If you don't send anything from the client to the server, the you have not way to find out that the server has indeed crashed. The only way to find out that the server crashed is by letting the client send something or by activating keep alive. If you send something to a server socket that does not exist, you will have to wait a rather long period, because TCP is going to try several times, with retransmits untill there is a server response. When TCP has retried several times, then it will finally bail out and if you have a blocking socket you will see that the send failed, which means you should close your socket.

Actually there is a third possible server disconnect, that is a reset, but this is exceptionally used. I assume here that if there is a gracefull server shutdown, a normal close on the socket on the server end is executed. Which will end up in a FIN being sent instead of a RST, which is the exceptional case.

Now back to your situation, if the server crashes, it is inherently in the design of TCP, because of all those retransmission timeouts and increasing delays, that you will have to wait some time to actually detect that there is a problem. If the server is gracefully closed and startup again, this is not the case, this you detect immediately by receiving 0 bytes.