Question

I’ve been struggling with this and can’t find a reason why my code is failing to properly read from a TCP server I’ve also written. I’m using the TcpClient class and its GetStream() method but something is not working as expected. Either the operation blocks indefinitely (the last read operation doesn’t timeout as expected), or the data is cropped (for some reason a Read operation returns 0 and exits the loop, perhaps the server is not responding fast enough). These are three attempts at implementing this function:

// this will break from the loop without getting the entire 4804 bytes from the server 
string SendCmd(string cmd, string ip, int port)
{
    var client = new TcpClient(ip, port);
    var data = Encoding.GetEncoding(1252).GetBytes(cmd);
    var stm = client.GetStream();
    stm.Write(data, 0, data.Length);
    byte[] resp = new byte[2048];
    var memStream = new MemoryStream();
    int bytes = stm.Read(resp, 0, resp.Length);
    while (bytes > 0)
    {
        memStream.Write(resp, 0, bytes);
        bytes = 0;
        if (stm.DataAvailable)
            bytes = stm.Read(resp, 0, resp.Length);
    }
    return Encoding.GetEncoding(1252).GetString(memStream.ToArray());
}

// this will block forever. It reads everything but freezes when data is exhausted
string SendCmd(string cmd, string ip, int port)
{
    var client = new TcpClient(ip, port);
    var data = Encoding.GetEncoding(1252).GetBytes(cmd);
    var stm = client.GetStream();
    stm.Write(data, 0, data.Length);
    byte[] resp = new byte[2048];
    var memStream = new MemoryStream();
    int bytes = stm.Read(resp, 0, resp.Length);
    while (bytes > 0)
    {
        memStream.Write(resp, 0, bytes);
        bytes = stm.Read(resp, 0, resp.Length);
    }
    return Encoding.GetEncoding(1252).GetString(memStream.ToArray());
}

// inserting a sleep inside the loop will make everything work perfectly
string SendCmd(string cmd, string ip, int port)
{
    var client = new TcpClient(ip, port);
    var data = Encoding.GetEncoding(1252).GetBytes(cmd);
    var stm = client.GetStream();
    stm.Write(data, 0, data.Length);
    byte[] resp = new byte[2048];
    var memStream = new MemoryStream();
    int bytes = stm.Read(resp, 0, resp.Length);
    while (bytes > 0)
    {
        memStream.Write(resp, 0, bytes);
        Thread.Sleep(20);
        bytes = 0;
        if (stm.DataAvailable)
            bytes = stm.Read(resp, 0, resp.Length);
    }
    return Encoding.GetEncoding(1252).GetString(memStream.ToArray());
}

The last one “works”, but it certainly looks ugly to put a hard-coded sleep inside the loop considering that sockets already support read timeouts! Do I need to setup some property(ies) on the TcpClient of the NetworkStream? Does the problem resides in the server? The server don’t close the connections, it is up to the client to do so. The above is also running inside the UI thread context (test program), maybe it has something to do with that…

Does someone know how to properly use NetworkStream.Read to read data until no more data is available? I guess what I’m wishing for is something like the old Win32 winsock timeout properties… ReadTimeout, etc. It tries to read until the timeout is reached, and then return 0… But it sometimes seem to return 0 when data should be available (or on the way.. can Read return 0 if is available?) and it then blocks indefinitely on the last read when data is not available…

Yes, I’m at a loss!

Answer 1

I answered (and asked) this back in 2012. Now in 2023 I’m using a much improved method to handle "timeout-based" End of Message (EOM) protocols, which I’ll share in place of the original, outdated and wrong answer.

I can’t stress enough how bad is any protocol in which termination is based on a read/connection timeout. The amount of pain I suffered trying to handle this is hard to express. But, as was my case, I could not change the other end, so I had to come up with ideas to mitigate the problems and make it as performant as possible, and I think that I now have the best possible bad solution to this 🙂

The basic idea remains the same as in the original answer: read data until no more data arrives after a specified inter-read timeout. It now improves it by adding a special case for the initial read to wait for data to start arriving with a "larger" initial timeout.

I’ve separated the reading code from the sending code. To read until "timeout" I’m now using the following:

public static void WaitForData(this NetworkStream stream, TimeSpan? timeout) {
    if (timeout is null) return;
    int originalReadTimeout = stream.ReadTimeout;
    stream.ReadTimeout = (int)timeout.Value.TotalMilliseconds;
    // performs a zero-byte read, e.g., don't read but waits for data unless the readtimeout is reached
    _ = stream.Read(Array.Empty<byte>(), 0, 0);
    stream.ReadTimeout = originalReadTimeout;
}

public static ReadOnlySpan<byte> ReadUntilTimeout(this NetworkStream stream, 
    TimeSpan? startTimeout = null,
    TimeSpan? readTimeout = null,
    int bufferSize = 8192 // same as TcpClient ReceiveBufferSize
    ) {
    stream.ReadTimeout = (int?)readTimeout?.TotalMilliseconds ?? stream.ReadTimeout;
    // if no data arrives within the start timeout a SocketException will be thrown!
    // ReadTimeout is automatically reset inside the wait bellow after it completes
    stream.WaitForData(startTimeout);
    var writer = new ArrayPoolBufferWriter<byte>();
    int readSize = -1;
    try {
        while (readSize != 0) {
            var buffer = writer.GetSpan(bufferSize);
            readSize = stream.Read(buffer);
            writer.Advance(readSize);
        }
    } catch(IOException ioe) when (ioe.InnerException is SocketException soe) {
        // ignores read timeout errors since that's what we want: read until closed or no more data available
        if (soe.SocketErrorCode != SocketError.TimedOut)
            throw soe;
    }
    return writer.WrittenSpan;
}

It improves in many ways my original answer, and also on other answers found here, as it doesn’t use Thread.Sleep, Spin.Wait or DataAvailable to check for data, it directly employs zero-byte reads against the underlying Socket, which will wait for data to arrive only if needed and in a very performant way, without any allocations whatsoever, and then proceed with the reads, until a read timeout is detected when data doesn’t arrive in time.

It’s easy to see how brittle this protocol is, since any network condition could affect the data transfer rate and trigger the timeout while there’s still data to be received. But, it’s the best way I found to handle this kind of predicament.

The SendCmd method could be rewritten like this:

static string SendCmd(string cmd, string ip, int port) {
    var client = new TcpClient(ip, port);
    var data = Encoding.GetEncoding(1252).GetBytes(cmd);
    var stm = client.GetStream();
    stm.Write(data, 0, data.Length);
    stm.Flush();
    var readSpan = stm.ReadUntilTimeout(
        startTimeout: TimeSpan.FromSeconds(10), 
        readTimeout: TimeSpan.FromMilliseconds(20));
    return Encoding.GetEncoding(1252).GetString(readSpan.ToArray());
}

You’ll notice that I’m using newer .NET constructions like ReadOnlySpan<byte> and also the amazing ArrayPoolBufferWriter from https://github.com/CommunityToolkit/dotnet which performs much better than MemoryStream for this kind of scenario.

I’ll also publish a nuget package with all these (hopefully) high performance networking functions wrapped for instant use.

---

OLD ANSWER (2012) for reference

Setting the underlying socket ReceiveTimeout property did the trick. You can access it like this: yourTcpClient.Client.ReceiveTimeout. You can read the docs for more information.

Now the code will only "sleep" as long as needed for some data to arrive in the socket, or it will raise an exception if no data arrives, at the beginning of a read operation, for more than 20ms. I can tweak this timeout if needed. Now I’m not paying the 20ms price in every iteration, I’m only paying it at the last read operation. Since I have the content-length of the message in the first bytes read from the server I can use it to tweak it even more and not try to read if all expected data has been already received.

I find using ReceiveTimeout much easier than implementing asynchronous read… Here is the working code:

string SendCmd(string cmd, string ip, int port)
{
  var client = new TcpClient(ip, port);
  var data = Encoding.GetEncoding(1252).GetBytes(cmd);
  var stm = client.GetStream();
  stm.Write(data, 0, data.Length);
  byte[] resp = new byte[2048];
  var memStream = new MemoryStream();
  var bytes = 0;
  client.Client.ReceiveTimeout = 20;
  do
  {
      try
      {
          bytes = stm.Read(resp, 0, resp.Length);
          memStream.Write(resp, 0, bytes);
      }
      catch (IOException ex)
      {
          // if the ReceiveTimeout is reached an IOException will be raised...
          // with an InnerException of type SocketException and ErrorCode 10060
          var socketExept = ex.InnerException as SocketException;
          if (socketExept == null || socketExept.ErrorCode != 10060)
              // if it's not the "expected" exception, let's not hide the error
              throw ex;
          // if it is the receive timeout, then reading ended
          bytes = 0;
      }
  } while (bytes > 0);
  return Encoding.GetEncoding(1252).GetString(memStream.ToArray());
}