.Net Socket doesn't respond to remote disconnect?

Question

I'm writing a small (C#) client application that sends data using a TCP/IP connection to a remote server. I'm using the standard .Net TcpClient object and want to leave the connection open from the client end as I am regularly submitting data packets to the server. However, it is possible that the server may close the connection, in which case I need to know to re-connect before sending my next packet.

Using Wireshark, I can see (only) the following dialogue when the server terminates the connection:

server >>> FIN, ACK ACK <<< client

What I do not see is my client responding with a FIN of its own, to complete the connection shutdown. The result is that my client program only finds out that the connection is down after sending the next data packet.

Is there any way I can set up TcpClient or its underlying Socket so as to complete the disconnect, and provide some feedback so that my client code knows to re-connect before sending the next packet?

Added in response to comment below: My sending code is very simple - the object that maintains the TcpClient and NetworkStream member variables, has a member function containing (essentially) the following:

bool sent = false;
byte[] buffer = Encoding.UTF8.GetBytes(dataString);
while (!sent)
{
    try
    {
        m_outStream.Write(buffer, 0, buffer.Length);
        sent = true;
    }
    catch (Exception ex)
    {
        if (m_outStream != null) { m_outStream.Dispose(); }
        m_client = new TcpClient(AddressFamily.InterNetwork);
        m_client.Connect(ipAddress, ipPort);
        m_outStream = m_client.GetStream();
    }
}

With m_client and m_outStream initialized, this simply performs a single pass every time. Then using Wireshark I can see the server send a packet with flags FIN, ACK to which the client responds with ACK.

The next time I call my function, the data is sent out with PSH, ACK, and the server responds with RST, ACK but does not read the incoming data. No exception is raised by the client.

Then I call my function a second time, and an exception is raised causing the connection to be re-started.

ntziolis · Accepted Answer · 2012-03-13T11:58:27.483

5

In general you should be able to use the Connected property on the TcpCient instance:

See here:
http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient.connected.aspx

However:

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.

Try the following to make sure the Connected flag holds the most recent state:

var tcpClient = new TcpClient ();
tcpClient.Connect();

var stream = tcpClient.GetStream();

// buffer size need to be > 0
int[] buffer = new int[1];
stream.Read(buffer, 0, 0);

if(!tcpClient.Connected)
    // do something

Based on decompilation it should be possible to read 0 bytes from a stream, at least there is no check in the .NET Framework TcpClient that prevents this. However it might not be aloud in the external code that is called from the framework to actually read from the network stream.

Be sure to Dispose of both the TcpClient and the Stream after your done, disposing the TcpClientdoes not dispose of the Stream so you need todo this manually, afterwards all resources are freed up (after GC).

edited Mar 13 '12 at 11:58

answered Mar 13 '12 at 11:35

ntziolis

9,895
1
32
49

Thanks for this comment, but the documentation states that Connected is only true as of the last Read/Write. My concern is that TcpClient is leaving the connection in a half-abandoned state. – Nick Mar 13 '12 at 11:38
I have updated my answer to give you an idea how to go about this. But in general the way the framework deals with Tcp Connections is that you are suppose to assume that it's open and gracefully handle when they are not . You are also responsible for cleaning up the `TcpClient` and the `Stream` as explained in my last paragraph. – ntziolis Mar 13 '12 at 11:57
Many thanks for the update - I guess that the `stream.Read` call does essentially the same as the Socket calls that I found out about, but at a higher level of abstraction. – Nick Mar 13 '12 at 12:03
There is actually a problem with the higher level code - NetworkStream.Read appears to block even when reading zero bytes, at least on a freshly-opened connection and stream, whereas the lower-level Socket calls do not block under the same circumstances. – Nick Mar 13 '12 at 12:36
thx, good to know! YOU could set read timeout though, a very small one for example this way you stop the stream from blocking after a short period of time. – ntziolis Mar 13 '12 at 12:42

score 3 · Answer 2 · edited May 23 '17 at 12:25

From MSDN TcpClient.Connected property:
Type: System.Boolean
true if the Client socket was connected to a remote resource as of the most recent operation; otherwise, false.

This means, you would have to send some data to the server to detect the broken connection. Reading does not work, as you read from the buffer.

See my answer on a related question (https://stackoverflow.com/a/25680975/2505186),
linking the answer of someone else, where a suitable way is described to detect the connection status: How to check if TcpClient Connection is closed?

Important for you:
The client does not close the connection automatically, when the server does so. The connection is in CLOSE_WAIT state then at the client side and in FIN_WAIT2 state at the server side. See the related section in the wikipedia article Transmission Control Protocol. Using the code from the linked answer above, you can detect that the connection is about to get closed. Further, you can finish the closing procedure then and reopen it if needed.

score 1 · Answer 3 · answered Jan 26 '16 at 13:34

The method I use for detecting connected status is this one.

static class SocketExtensions
    {
        /// <summary>
        /// Extension method to tell if the Socket REALLY is closed
        /// </summary>
        /// <param name="socket"></param>
        /// <returns></returns>
        public static bool IsConnected(this Socket socket)
        {
            try
            {
                return !(socket.Poll(1, SelectMode.SelectRead) && socket.Available == 0);
            }
            catch (SocketException) { return false; }
        }
    }

When I want to shutdown the connection, I call the following. Closing the underlying stream, and then the client object on top. I enclose it in trys and catches to ensure that an attempt at closing them is attempted on each. Note: PeerStream in this case is the NetworkStream (from Client.GetStream())

/// <summary>
        /// Method will disconnect this peer forcefully
        /// </summary>
        public void Disconnect()
        {
            try
            {
                PeerStream.Close();
            }
            catch (Exception ee)
            {
            }
            try
            {
                _client.Client.Disconnect(false);
            }
            catch (Exception ee)
            {

            }
        }

score 0 · Answer 4 · answered Mar 13 '12 at 12:01

0

I have found a partial answer to my question that solves the immediate problem.

While I still don't know if I can get my TcpClient to complete the disconnection, I can reliably discover whether the socket has disconnected using the following code:

if (m_client.Client.Poll(1000, SelectMode.SelectRead) 
&& (m_client.Client.Available == 0))
{
    // Connection has gone - reconnect!
    m_client = new TcpClient(AddressFamily.InterNetwork);
    m_client.Connect(ipAddress, ipPort);
}
else
{
    // Connection is good, nothing to do
}

answered Mar 13 '12 at 12:01

Nick

1,460
1
14
20

nice, just one note: Rather than focusing on detecting that the connection is open the best practice is to assume that it's open and instead prepare your code to handle exceptions gracefully, since there is no way of telling whether it has been closed in between your check and when you send/receive your data, so you need to handle these exceptions anyway. – ntziolis Mar 13 '12 at 12:08
Yes indeed, My code is set up to handle exceptions. My problem is that with the connection only half closed, my first data packet _is_ sent only to be rejected by the server using the RST flag. However, this is not enough to raise an exception. It is only when I _next_ try to send a data packet that the exception occurs, by which time I have already lost the preceding packet. – Nick Mar 13 '12 at 12:33
ok this sounds like you are doing something wrong, there should definitely be an exception, can you post your code? – ntziolis Mar 13 '12 at 12:43

.Net Socket doesn't respond to remote disconnect?

4 Answers4

Linked