Stream Reading

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • =?Utf-8?B?VHJlY2l1cw==?=

    #1

    Stream Reading

    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(bu ffer, 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.Re ad(...)) 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
  • =?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=

    #2
    Re: Stream Reading

    Trecius wrote:
    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(bu ffer, 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.Re ad(...)) and just wait there until timeout. This isn't very
    efficient.
    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
    If you have problems with reading the stream in blocks, why not simply
    use a StreamReader that handles that for you?

    --
    Göran Andersson
    _____
    Göran Anderssons privata hemsida.

    Comment

    • Marc Gravell

      #3
      Re: Stream Reading

      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(buf fer, 0, buffer.Length)) 0)
      {
      // Process "bytesRead" byes from the buffer
      }

      Marc

      Comment

      Working...