Question

I am working on a TcpClient Asynchronous requesting WPF project. In which I have written some code when ever client gets disconnected with out network lost due to socket disconnected. Its working fine, and when the socket is removed/unplugged also on the server side no event is firing or no exception recieved to make the client status disconnected. I have seen about this issue in many sites, every where people used to say to use the Socket.Poll method but which is not working in my case. The SelectMode.SelectRead is always returning true when the client connected or disconnected, so I cant find any alternative.

So, I am posting my question here to know how to find when a client socket is unplugged/network access has been lost in asynchronous mode. I have tried with following code, any how its not working.

    void CheckSocketStatus()
    {
        try
        {
            while (true)
            {
                System.Threading.Thread.Sleep(1000);
                if(!mobjClient.Client.Poll(0,SelectMode.SelectWrite))
                {
                    break;
                }
            }
        }
        catch(SocketException soex)
        {

        }
    }

Hope someone can help me.

Answer 1

It is correct that this cannot be used to detect certain connection problems as by the documentation that states:

This method cannot detect certain kinds of connection problems, such as a broken network cable, or that the remote host was shut down ungracefully. You must attempt to send or receive data to detect these kinds of errors.

You should probably consider not relying on a persistent connection and instead open/close it on demand. Nevertheless, if you need some kind of connection state information, the unfortunate conclusion is that the underlying architecture does not provide it. You’ll have to do it by periodically exchanging packets and catching errors.

This is also what the documentation on the Connected property of TcpClient suggests:

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.