Stream Reading -- Again

[=?Utf-8?B?VHJlY2l1cw==?=]

I've made a post last Friday in regards to this subject, but I'm still a
little lost.

I've a problem regarding reading a stream. I am connected to a port that
sends information using a stream. I can read the information from the stream
with no problem. However, the problem comes when there is nothing to read in
the stream. The stream is still open, so it just hangs on my Read().

EXA:

byte[] buffer = new buffer[2048];
int nBytes
while ((nBytes = this.m_stream.R ead(buffer, 0, buffer.Length)) 0)
{
// Process bytes
}
Well, my problem -- as mentioned -- is here. For example, if the stream
only sends 64 bytes. I will read once, I will process once, and then I will
jump to back to the top of the while-statement where it will Read() again,
but it will just hang here. Should I be doing active monitoring on the
buffer to determine if the EOF string has been received? In my case, the EOT
is three hashmarks: ###. Should I be watching for the three hashmarks and
break out of the loop to prevent hanging?

If I should be watching for the EOT, or ###, should I also watch for the EOT
on a boundary? For example, in one packet it may send ## and the next packet
may contain a solitary #. Or, another example, if I read 2048 of bytes, that
will fill up my entire buffer. The last byte in the buffer may be a #. Then
I read again on the stream and the next two -- and only bytes -- are ##.
Well, this would mean I am at the end. Thank you.

Trecius

[Winfried Wille]

Hello Trecius,

you can use a non blocking read by using BeginRead instead of Read, you will
probably find a example for this on google.

Regards
Winfried Wille

[Peter Duniho]

On Mon, 20 Oct 2008 11:19:01 -0700, Trecius
<Tr*****@discus sions.microsoft .comwrote:

[...]
Well, my problem -- as mentioned -- is here. For example, if the stream
only sends 64 bytes. I will read once, I will process once, and then I
will
jump to back to the top of the while-statement where it will Read()
again,
but it will just hang here. Should I be doing active monitoring on the
buffer to determine if the EOF string has been received? In my case,
the EOT
is three hashmarks: ###. Should I be watching for the three hashmarks
and
break out of the loop to prevent hanging?

You haven't explained exactly what kind of stream this is. But yes, if
the stream itself doesn't have a natural "end" (e.g. a FileStream would
reach the actual end of the file, a NetworkStream would be closed, etc.),
then you'll have to watch the data yourself.

And yes, since the three-byte terminator for the stream may be read in
separate parts in separate calls to Read(), you need to correctly deal
with that.

Pete