TcpClient.Close doesn't close the connection

Question

I have an application that uses TcpClient and TcpListener to communicate over the network. However, when I call TcpClient.Close on the client to disconnect it from the server, the server doesn't react at all.

Now, before you post a comment about this question being a duplicate of this one, and how the solution can be found here, believe me when I say that I've already found these and tried them. It doesn't help. I've also tried different combinations of TcpClient.Close, TcpClient.GetStream().Close(), and TcpClient.Dispose. Nothing works.

The code is nothing noteworthy, just a Disconnect method in the client that resets all of the variables for reuse, and closes all network resources. The server has a loop that checks if TcpClient.Connected is true or not, and if it's false, it's supposed to jump out of the loop and terminate the thread.

Any ideas?

Solution 1

The TcpClient.Connected should pretty much be ignored. It basically represents whether the last communication was successful. From MSDN (emphasis mine):

Because the Connected property only reflects the state of the connection as of the most recent operation, you should attempt to send or receive a message to determine the current state. After the message send fails, this property no longer returns true. Note that this behavior is by design. You cannot reliably test the state of the connection because, in the time between the test and a send/receive, the connection could have been lost. Your code should assume the socket is connected, and gracefully handle failed transmissions.

If you call Close() on the client side, nothing is sent to the server to tell it that its closing, it literally just closes it self so that the client can't use it any more. The only reliable way to determine if you're still connected is to try to send data and handle the failure. If you want you could implement your own handshake agreement where when you call Close() you send a special notification to the server alerting it to the fact but there will still be times when that packet never reaches the server.

Solution 2

Listen for one byte, if it's received, get the rest. If Receiving the one byte returns 0, client disconnected.

        IPAddress nReceiveAddress = IPAddress.Parse(GetIp(sSource));
        IPEndPoint localEndPoint = new IPEndPoint(nReceiveAddress, GetPort(sSource));
        Socket nSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
        nSocket.Bind(localEndPoint);

        nSocket.Listen(10);
        Socket nSocketClient = nSocket.Accept();

                byte[] bufferOne = new byte[1];
                int nBytes = nClient.Receive(bufferOne);

                if (nBytes == 0)
                {
                    AppendToLog(String.Format("{0}: Closing.", sName));
                    nClient.Close();
                }
                else
                {
                    byte[] buffer = null;
                    buffer = new byte[nClient.Available + 1];

                    if (nClient.Available > 0)
                        nBytes = nClient.Receive(buffer);

                    if(nBytes>0)
                    {
                        //KS effectively insert the first received byte at start.
                        Array.Copy(buffer, 0, buffer, 1, buffer.Length - 1);
                        buffer[0] = bufferOne[0];
                    }
                }

Comments

[Bevin]

Thank you so much! All I had to do was send a disconnect message to the server. I thought I could do it by just calling the method and having the sockets figure it out on their own, but life isn't that easy, I suppose.

[Chris Haas]

@Bevin, just make sure that the server handles the disconnects that don't get a chance to send off the disconnect message, too.

[reirab]

Actually, the statement that nothing is sent to the server to tell it that it's closing is not true for a TCP connection. When a TCP connection is terminated normally, the side wishing to initiate the connection termination sends a message with the FIN flag set. Unfortunately, it doesn't appear that the NetworkStream or TcpClient classes have any way of detecting that this has occurred, even though the underlying sockets API does. So, practically speaking, Chris' answer is a correct solution to the problem.