Stream Reading

  • Thread starter Thread starter Trecius
  • Start date Start date
T

Trecius

Hello, Newsgroupians:

In regards to reading a stream, I know we use the Read() method. One could
implement reading a stream using a while-loop.

while (stream.Read(buffer, 0, buffer.Length) != 0)
{
// Process the buffer
}

However, there's a flaw with this implementation. Let's say the buffer is
256 bytes long. Some information is sent down the stream, which is on the
other end, that is 64 bytes long. On our end the stream is Read(), and it
reads all 64 bytes. Well, once read, it will jump back up to the
while(stream.Read(...)) and just wait there until timeout. This isn't very
efficient.

In my case I know the stream's terminating string. It's a the string ###.
Would it be wise for me to watch for the termination string in my while-loop
and jump out of it when I detect it?

If it is wise of me to do it, should I be worried about the termination
string on a packet boundary? For example, the end of one packet may contain
## and then terminates. This packet is then followed by another packet
containing the final #. Should I put in previsions for this situation? Is
there a more simplistic method that I should be using?

Thank you, all.


Trecius
 
Trecius said:
Hello, Newsgroupians:

In regards to reading a stream, I know we use the Read() method. One could
implement reading a stream using a while-loop.

while (stream.Read(buffer, 0, buffer.Length) != 0)
{
// Process the buffer
}

However, there's a flaw with this implementation. Let's say the buffer is
256 bytes long. Some information is sent down the stream, which is on the
other end, that is 64 bytes long. On our end the stream is Read(), and it
reads all 64 bytes. Well, once read, it will jump back up to the
while(stream.Read(...)) and just wait there until timeout. This isn't very
efficient.
Click to expand...

That should be no problem. The Read method returns zero when there is no
more data in the stream.

It has another serious flaw, though. The Read method returns the number
of bytes actually placed in the buffer, but all you do with that value
is to check if it's different from zero. That means that you don't know
how much of the buffer contains data read from the stream, and how much
contains garbage.
In my case I know the stream's terminating string. It's a the string ###.
Would it be wise for me to watch for the termination string in my while-loop
and jump out of it when I detect it?

If it is wise of me to do it, should I be worried about the termination
string on a packet boundary? For example, the end of one packet may contain
## and then terminates. This packet is then followed by another packet
containing the final #. Should I put in previsions for this situation? Is
there a more simplistic method that I should be using?

Thank you, all.


Trecius
Click to expand...

If you have problems with reading the stream in blocks, why not simply
use a StreamReader that handles that for you?
 
You need to track how much data was read. Personally I always test for
+ve, but that might be paranoia...

int bytesRead;
while ((bytesRead = stream.Read(buffer, 0, buffer.Length)) > 0)
{
// Process "bytesRead" byes from the buffer
}

Marc
 
Back
Top