NetworkStream.R ead blocking question

[Cyron]

Hello Friends,

When I make a call to NetworkStream.R ead(byte[] buffer, int offset,
int size) I have found that this method will block until size bytes
have been read or the connection is closed. Is this the correct
behavior? My MSDN documentation led me to believe that this function
should block until at least 1 byte of data was available, the
connection was closed, or size bytes of data had been read.

Any comments or clarifications would be greatly appreciated.

Thanks,

Mike

[William Stacey [MVP]]

NS.Read ends up doing a:
int read = socket.Receive( buffer, offset, size, SocketFlags.Non e);

So its blocking behavior should be the same as that of calling
socket.Receive yourself. This will block until you get at least 1 byte. So
your not getting 1 byte after some time or maybe you have another stream
ontop of NS that is blocking for X bytes. Are you sure your getting some
data and it is still blocking?

--
William Stacey [MVP]

"Cyron" <md*******@yaho o.comwrote in message
news:11******** **************@ b28g2000cwb.goo glegroups.com.. .
| Hello Friends,
|
| When I make a call to NetworkStream.R ead(byte[] buffer, int offset,
| int size) I have found that this method will block until size bytes
| have been read or the connection is closed. Is this the correct
| behavior? My MSDN documentation led me to believe that this function
| should block until at least 1 byte of data was available, the
| connection was closed, or size bytes of data had been read.
|
| Any comments or clarifications would be greatly appreciated.
|
| Thanks,
|
| Mike
|

[Jon Skeet [C# MVP]]

Cyron <md*******@yaho o.comwrote:

When I make a call to NetworkStream.R ead(byte[] buffer, int offset,
int size) I have found that this method will block until size bytes
have been read or the connection is closed.

That's certainly not *always* the case. I've seen NetworkStream return
having read fewer than "size" bytes, even when there's more data
available later. You shouldn't make assumptions as to how much data
will be returned, beyond that it will be between 1 byte and "size"
bytes, if the stream is still open and data is or becomes available.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,
"Cyron" <md*******@yaho o.comwrote in message
news:11******** **************@ b28g2000cwb.goo glegroups.com.. .

Hello Friends,

When I make a call to NetworkStream.R ead(byte[] buffer, int offset,
int size) I have found that this method will block until size bytes
have been read or the connection is closed. Is this the correct
behavior? My MSDN documentation led me to believe that this function
should block until at least 1 byte of data was available, the
connection was closed, or size bytes of data had been read.

You better prepare your code for not a consistent behavior. It does depend
of the lower layers of how many bytes you get. The only thing you know for
sure is that you will not get more than thesize of the buffer.

My guess is that it does post the same amount of data it got from the
network. You can see how this work by playing around with the array size &
the TCP buffer's size.
--
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Cyron]

You better prepare your code for not a consistent behavior. It does depend

of the lower layers of how many bytes you get. The only thing you know for
sure is that you will not get more than thesize of the buffer.

My guess is that it does post the same amount of data it got from the
network. You can see how this work by playing around with the array size &
the TCP buffer's size.

Thanks for the comments and suggestions everyone. I'm sorry I was a
little unclear in my initial post. I do most of my network programming
with unix sockets and was expecting NetworkStream.R ead to have have
similar blocking properties -- ie. the call returns when there is at
least 1 byte of data available. It turns my C# code was correct,
however an associate had previously used this machine to develop a
driver which modified the lower level network stack. I tested the code
on 5 other vanilla Windows boxes and it works as expected.

Thanks again for your time and suggestions,

Mike