What Are Some Reasons Networkstream.Read Would Hang/Block

What are some reasons NetworkStream.Read would hang/block?

The Remarks section of the documentation for NetworkStream.Read is misleading. It says:

This method reads data into the buffer parameter and returns the number of bytes successfully read. If no data is available for reading, the Read method returns 0. The Read operation reads as much data as is available, up to the number of bytes specified by the size parameter. If the remote host shuts down the connection, and all available data has been received, the Read method completes immediately and return zero bytes.

It should say:

This method reads data into the buffer parameter and returns the number of bytes successfully read. If no data is available for reading, the Read method blocks until data becomes available or the connection is closed. The Read operation reads as much data as is available, up to the number of bytes specified by the size parameter. If the remote host shuts down the connection, and all available data has been received, the Read method completes immediately and return zero bytes.

C# Networkstream.read()

No, it will not block.
The Read operation reads as much data as is available, up to the number of bytes specified by the size parameter.
Source: http://msdn.microsoft.com/en-us/library/system.net.sockets.networkstream.read.aspx

Given it will not wait for that extra 1 byte, if you are expecting it, you should implement a loop to continue reading the stream. You can exit the loop however you feel best.

---

UPDATE:
I was wrong when I stated "There's no blocking at all. If no data is available for reading, the Read method returns 0", but I was correct when I stated that it wouldn't block waiting to fill the entire buffer which it the scenario described in Kazoom's question.

Updated to demonstrate that NetworkStream.Read blocks waiting for the first byte, but does not block waiting to fill the entire buffer.

Create to console projects

On one end, you have the listener:

IPEndPoint ep = new IPEndPoint(IPAddress.Parse("127.0.0.1"), 12345);
TcpListener listener = new TcpListener(ep);
listener.Start();
TcpClient client = listener.AcceptTcpClient();
NetworkStream s = client.GetStream();
byte[] buffer = new byte[32];
Console.WriteLine(s.Read(buffer, 0, 32));
Console.WriteLine("Press any key to continue...");
Console.Read();

On the other end, we send only one byte:

IPEndPoint ep = new IPEndPoint(IPAddress.Parse("127.0.0.1"), 12345);
TcpClient client = new TcpClient();
client.Connect(ep);
client.GetStream().Write(new byte[] { 60 }, 0, 1);
Console.WriteLine("Press any key to continue...");
Console.Read();

Both sides will run until they reach Console.Read(). Notice that the listener does not block on Read.

The listener will print "1"

Why is NetworkStream.Read so slow?

I just found the solution to my slow network problem and I want to share it with all of you. You never know when or who might experience the same problem.

Earlier this day I came to this site TcpClient receive delay of over 500ms and there I followed the solution of the registry hack of the PSH bit (IgnorePushBitOnReceives) and that solved it. So we have now temporary fast communication back because I think the people of the hardware where we are working with, just need to set the Push flag of the TCP messages.

Read bytes from NetworkStream (Hangs)

The implementation will block until at least one byte of data can be
read, in the event that no data is available.

From MSDN

Your server propably isn't sending you any data.

Edit:

I tested your client and it works perfectly fine. Try it yourself and set the following parameters:

  string server = "google.com";
  int port = 80;
  string message = "GET /\n";

It's definitely your server which has the problem.

TcpClient Stream.Read ends thread unexpectedly

Seems like your Read() blocks, because no data is available to be read. Look here for more information: What are some reasons NetworkStream.Read would hang/block?

If I am right, the reason is the server doesn't send data. Try debugging the server, not client.

---

Related Topics