Question: Let's say you have 2 applications, server and client. I'm debugging them at the same time in 2 instances of visual studio 2010. Let's say that on the client side I call:

```
                _reader.Close(); //BinaryReader

                _writer.Close(); //BinaryWriter

                _ssl.Close();    //SslStream taken from _stream

                _stream.Close(); //NetworkStream from _client.GetStream();

                _client.Close(); //TcpClient

```

and I've checked through the debugger that this code is executed. **After this, I also trigger, with other instructions, the closure of the client application, infact visual studio exits from debug mode and goes back to standard mode**.

In the server application, since the connection is actually closed, a pending \_reader.Read() fails, triggering an exception which is properly handled in a try/catch. This, according to [TcpClient.Connected Remarks](http://msdn.microsoft.com/it-it/library/system.net.sockets.tcpclient.connected.aspx) should update the value of TcpClient.Connected accordingly.

This doesn't happen: a different thread in the server keeps checking \_client.Connected but it's still true. 

You should note that:

1) If I close the client using the "Stop" button everything works seamlessly, \_client.Connected becomes false

2) Don't know is this may be relevant, but server listens on 127.0.0.1 and client connects to 127.0.0.1 since I'm debugging these 2 apps on a single pc

Answer: 
The Connected property is updated only when you call Write or Read.
I don't know if this may interest anyone, but I'll tell you how I solved this issue. Since TcpClient.Connected doesn't seem to be reliable, (under certain conditions it will still be true even after a failed read attempt on the underlying stream) instead of checking the connection status from TcpClient.Connected, I use a bool "disconnected". 

Such bool value is managed by the thread which was listening from such TcpClient (through a BinaryReader):

when a read fails -> it means that the connection has been closed -> an exception is generated and it's gracefully handled by a try/catch, where:

```
try
{
   reader.Read();
}

catch
{
   disconnect = true;
}

```