Can NetworkStream.Write() block?

[Gaz]

myNetworkStream.Write(byte[], int offset, int size);

From the MSDN documentation:
"
Remarks:
The Write method starts at the specified offset and sends size bytes
from the contents of buffer to the network. The Write method blocks
until the requested number of bytes is sent or a SocketException is
thrown. If you receive a SocketException, use the
SocketException.ErrorCode property to obtain the specific error code,
and refer to the Windows Sockets version 2 API error code documentation
in MSDN for a detailed description of the error.
"

It says the call blocks until the bytes are sent but aren't the bytes
just queued to the write buffer until the OS feels like sending them
over the wire? Therefore doesn't the call always return pretty much
immediately anyway?

Thanks.

 

[Jesse Houwing]

Hello GAZ,

myNetworkStream.Write(byte[], int offset, int size);

From the MSDN documentation:
"
Remarks:
The Write method starts at the specified offset and sends size bytes
from the contents of buffer to the network. The Write method blocks
until the requested number of bytes is sent or a SocketException is
thrown. If you receive a SocketException, use the
SocketException.ErrorCode property to obtain the specific error code,
and refer to the Windows Sockets version 2 API error code
documentation
in MSDN for a detailed description of the error.
"
It says the call blocks until the bytes are sent but aren't the bytes
just queued to the write buffer until the OS feels like sending them
over the wire? Therefore doesn't the call always return pretty much
immediately anyway?

My guess is that it'll block if the buffer is full.

 

[Gaz]

Hello GAZ,

myNetworkStream.Write(byte[], int offset, int size);

From the MSDN documentation:
"
Remarks:
The Write method starts at the specified offset and sends size bytes
from the contents of buffer to the network. The Write method blocks
until the requested number of bytes is sent or a SocketException is
thrown. If you receive a SocketException, use the
SocketException.ErrorCode property to obtain the specific error code,
and refer to the Windows Sockets version 2 API error code
documentation
in MSDN for a detailed description of the error.
"
It says the call blocks until the bytes are sent but aren't the bytes
just queued to the write buffer until the OS feels like sending them
over the wire? Therefore doesn't the call always return pretty much
immediately anyway?

My guess is that it'll block if the buffer is full.

Thank you.

It seems this is better than using the non-blocking version
myNetworkStream.BeginWrite(byte[] buffer, int offset, int size) since
all that does (if the write buffer is full) is create a backlog of
BeginWrite threads all waiting to complete. And what happens when
/that/ buffer is full? another blockage?

Might as well use the blocking version and increase the buffer size if
that is possible.

 

[Jeroen Mostert]

myNetworkStream.Write(byte[], int offset, int size);

It seems this is better than using the non-blocking version
myNetworkStream.BeginWrite(byte[] buffer, int offset, int size) since
all that does (if the write buffer is full) is create a backlog of
BeginWrite threads all waiting to complete.

This is *not* what happens. The BeginX methods generally do *not* create
threads at all to handle the asynchronous requests, because that doesn't
scale. Instead, they use overlapped I/O when possible. Do not assume that
the asynchronous methods are built on the synchronous methods, because it's
generally the other way around.

In general, you can assume asynchronous calls are *more* efficient than
their synchronous companions, since those *always* take up a thread (namely
the thread waiting for completion) while the asynchronous ones generally
only take up a thread when executing the completion callback.

Might as well use the blocking version and increase the buffer size if
that is possible.

For overlapped I/O (which .NET uses whenever possible) there's no blocking.
The overlapped requests are simply queued until there's an opportunity to
process them. In the rare event that the requests (plus their associated
buffers) overflow the queue, you'd get a SocketException, but I'm almost
certain there's no blocking. (Almost certain -- if a .NET networking guru
could pipe up and confirm or deny this, I'd be grateful.)