title: Detecting client TCP disconnection while using NetworkStream class
body: <p>A friend of mine came to me with a problem: when using the NetworkStream class on the server end of the connection, if the client disconnects, NetworkStream fails to detect it.</p>
  
  <p>Stripped down, his C# code looked like this:</p>
  
  <pre class="lang-c# prettyprint-override"><code>List&lt;TcpClient&gt; connections = new List&lt;TcpClient&gt;();
  TcpListener listener = new TcpListener(7777);
  listener.Start();
  
  while(true)
  {
      if (listener.Pending())
      {
          connections.Add(listener.AcceptTcpClient());
      }
      TcpClient deadClient = null;
      foreach (TcpClient client in connections)
      {
          if (!client.Connected)
          {
              deadClient = client;
              break;
          }
          NetworkStream ns = client.GetStream();
          if (ns.DataAvailable)
          {
              BinaryFormatter bf = new BinaryFormatter();
              object o = bf.Deserialize(ns);
              ReceiveMyObject(o);
          }
      }
      if (deadClient != null)
      {
          deadClient.Close();
          connections.Remove(deadClient);
      }
      Thread.Sleep(0);
  }
  </code></pre>
  
  <p>The code works, in that clients can successfully connect and the server can read data sent to it. However, if the remote client calls tcpClient.Close(), the server does not detect the disconnection - client.Connected remains true, and ns.DataAvailable is false.</p>
  
  <p>A search of Stack Overflow provided <em>an</em> answer - since Socket.Receive is not being called, the socket is not detecting the disconnection. Fair enough. We can work around that:</p>
  
  <pre class="lang-c# prettyprint-override"><code>foreach (TcpClient client in connections)
  {
      client.ReceiveTimeout = 0;
      if (client.Client.Poll(0, SelectMode.SelectRead))
      {
          int bytesPeeked = 0;
          byte[] buffer = new byte[1];
          bytesPeeked = client.Client.Receive(buffer, SocketFlags.Peek);
          if (bytesPeeked == 0)
          {
              deadClient = client;
              break;
          }
          else
          {
              NetworkStream ns = client.GetStream();
              if (ns.DataAvailable)
              {
                  BinaryFormatter bf = new BinaryFormatter();
                  object o = bf.Deserialize(ns);
                  ReceiveMyObject(o);
              }
          }
      }
  }
  </code></pre>
  
  <p>(I have left out exception handling code for brevity.)</p>
  
  <p>This code works, however, I would not call this solution "elegant". The other elegant solution to the problem I am aware of is to spawn a thread per TcpClient, and allow the BinaryFormatter.Deserialize (née NetworkStream.Read) call to block, which would detect the disconnection correctly. Though, this does have the overhead of creating and maintaining a thread per client.</p>
  
  <p>I get the feeling that I'm missing some secret, awesome answer that would retain the clarity of the original code, but avoid the use of additional threads to perform asynchronous reads. Though, perhaps, the NetworkStream class was never designed for this sort of usage. Can anyone shed some light?</p>
  
  <p><strong>Update:</strong> Just want to clarify that I'm interested to see if the .NET framework has a solution that covers this use of NetworkStream (i.e. polling <em>and</em> avoiding blocking) - obviously it can be done; the NetworkStream could easily be wrapped in a supporting class that provides the functionality. It just seemed strange that the framework essentially requires you to use threads to avoid blocking on NetworkStream.Read, or, to peek on the socket itself to check for disconnections - almost like it's a bug. Or a potential lack of a feature. ;)</p>