Difference between NetworkStream.Read() and NetworkStream.BeginRead()?

Question

I need to read from NetworkStream which would send data randomly and the size of data packets also keep varying. I am implementing a multi-threaded application where each thread would have its own stream to read from. If there is no data on the stream, the application should keep waiting for the data to arrive. However, if the server is done sending data and has terminated the session, then it should exit out.

Initially I had utilised the Read method to obtain the data from the stream, but it used to block the thread and kept waiting until data appeared on the stream.

The documentation on MSDN suggests,

If no data is available for reading, the Read method returns 0. If the remote host shuts down the connection, and all available data has been received, the Read method completes immediately and return zero bytes.

But in my case, I have never got the Read method to return 0 and exit gracefully. It just waits indefinitely.

In my further investigation, I came across BeginRead which watches the stream and invokes a callback method asynchronously, as soon as it receives the data. I have tried to look for various implementations using this approach as well, however, I was unable to identify when would using BeginRead be beneficial as opposed to Read.

As I look at it, BeginRead has just the advantage of having the async call, which would not block the current thread. But in my application, I already have a separate thread to read and process the data from stream, so that wouldn't make much difference for me.

• Can anyone please help me understand the Wait and Exit mechanism for BeginRead and how is it different from Read?

• What would be the best way to implement the desired functionality?

Solution 1

I use BeginRead, but continue blocking the thread using a WaitHandle:

byte[] readBuffer = new byte[32];
var asyncReader = stream.BeginRead(readBuffer, 0, readBuffer.Length, 
    null, null);

WaitHandle handle = asyncReader.AsyncWaitHandle;

// Give the reader 2seconds to respond with a value
bool completed = handle.WaitOne(2000, false);
if (completed)
{
    int bytesRead = stream.EndRead(asyncReader);

    StringBuilder message = new StringBuilder();
    message.Append(Encoding.ASCII.GetString(readBuffer, 0, bytesRead));
}

Basically it allows a timeout of the async reads using the WaitHandle and gives you a boolean value (completed) if the read was completed in the set time (2000 in this case).

Here's my full stream reading code copied and pasted from one of my Windows Mobile projects:

private static bool GetResponse(NetworkStream stream, out string response)
{
    byte[] readBuffer = new byte[32];
    var asyncReader = stream.BeginRead(readBuffer, 0, readBuffer.Length, null, null);
    WaitHandle handle = asyncReader.AsyncWaitHandle;

    // Give the reader 2seconds to respond with a value
    bool completed = handle.WaitOne(2000, false);
    if (completed)
    {
        int bytesRead = stream.EndRead(asyncReader);

        StringBuilder message = new StringBuilder();
        message.Append(Encoding.ASCII.GetString(readBuffer, 0, bytesRead));

        if (bytesRead == readBuffer.Length)
        {
            // There's possibly more than 32 bytes to read, so get the next 
            // section of the response
            string continuedResponse;
            if (GetResponse(stream, out continuedResponse))
            {
                message.Append(continuedResponse);
            }
        }

        response = message.ToString();
        return true;
    }
    else
    {
        int bytesRead = stream.EndRead(asyncReader);
        if (bytesRead == 0)
        {
            // 0 bytes were returned, so the read has finished
            response = string.Empty;
            return true;
        }
        else
        {
            throw new TimeoutException(
                "The device failed to read in an appropriate amount of time.");
        }
    }
}

Solution 2

Async I/O can be used to achieve the same amount of I/O in less threads.

As you note, right now your app has one thread per Stream. This is OK with small numbers of connections, but what if you need to support 10000 at once? With async I/O, this is no longer necessary because the read completion callback allows context to be passed identifying the relevant stream. Your reads no longer block, so you don't need one thread per Stream.

Whether you use sync or async I/O, there is a way to detect and handle stream closedown on the relevant API return codes. BeginRead should fail with IOException if the socket has already been closed. A closedown while your async read is pending will trigger a callback, and EndRead will then tell you the state of play.

When your application calls BeginRead, the system will wait until data is received or an error occurs, and then the system will use a separate thread to execute the specified callback method, and blocks on EndRead until the provided NetworkStream reads data or throws an exception.

Comments

[Steve Townsend]

The implication that multiple processes are involved here is totally wrong.

[Danish Khan]

Thanks @Steve. The one thread per stream is due to a lot of other design considerations and isn't really an issue. We would have 10 simultaneous threads at the max.

[Danish Khan]

@ Steve, I think @ Bonshington meant 'Thread', when he said 'Process'.

[Danish Khan]

Thanks @GenericTypeTea, This looks like an interesting approach, but there is no way for me to determine a correct timeout period. Nevertheless, I think this can be modified a bit to get a resolution to my problem. I'd try out and report, if successful. BTW, your handle got me smiling.. :)

[SpeksETC]

If I'm not mistaken you must always call EndABC on each BeginABC call. In the code above, if there is a timeout, End never gets called. A callback that calls End (and handles any possible exceptions) should probably be added to the above code.

[djdd87]

@SpeksETC - I think you are mistaken. I always call an end: int bytesRead = stream.EndRead(asyncReader);, but perhaps I should change the code to call that code directly after the line bool completed = handle.WaitOne(2000, false); in order to remove duplication.