Also, the other code snippet was thrown together hastily just to test
for the truncation.  It has not been thoroughly tested.  Neither is it
very elegant.

It may wait for the *first* time, but possibly not afterwards. I'll try
to prove it either way though.

Happy to help :)

<snip>

That one's a problem to start with - it will only keep going while
there is data available *now*, rather than until the stream is closed
at the server end.

You should really just read until the call to Read returns 0.

I assume the server *is* closing its end of the stream, by the way?

The next statement after the call to Peek() only executes when Peek()  
returns something other than -1.  Are you sure that it's not just that  
Peek() keeps returning -1?

And I reiterate: given that the docs say that Peek() will return -1 if no  
data is available, under what condition would Peek() block?  Conversely,  
feel free to describe a condition under which Peek() would return -1.

For better or worse, your question is likely to get exactly the same  
attention anyone else's does.  If you have an urgent situation, you may  
want to consider paid developer support from Microsoft.  You'll find that  
many of us are reasonably responsive, but there's not likely to be any  
point in expressing your urgency.  And at worst, it implies that we are  
are your beck and call, which is surely not the implication you intended.

You're welcome.  :)

I see at least four problems in that code, at least three of which I  
believe are significant.

Specifically:

At the very least, you have a problem any time that a Unicode character  
gets split in two during network transmission.  You also aren't taking  
into account the actual count of BytesRead when you convert the buffer to  
a string, but since the buffer is zero-filled and you allocate it anew  
each time (inefficient, but workable) I think this isn't as likely to  
cause a problem.

What happens when you receive more than one message in a single read?  
You're just discarding whatever text was read after the current message's  
EOM.

Like Peek(), the DataAvailable property doesn't tell you anything about  
the future condition of the stream.  So if you stop here, then as soon as  
the stream gets temporarily interrupted you incorrectly will detect that  
as the end of the message.  Of course, if the actual EOM text hasn't  
arrived yet, your code breaks.

Pete

It turns out, Peek() does block, sort of.  I wrote a little Stream  
implementation (attached below) that's just a wrapper for an actual  
Stream, but which introduces network-like behavior: you can configure it  
so that it returns something less than what was asked for, and so that the  
completion of the operation is delayed by some amount (with these  
optionally being randomized).

I used this implementation to empirically look at what StreamReader does.  
In fact, I was able to see that the first time you call Peek(), it  
actually reads what it can.  If it can put anything into its internal  
buffer, Peek() will return that data.  It will continue to do so until it  
exhausts its internal buffer.

Here's the very important part: once it's exhausted its internal buffer,  
Peek() DOES NOT attempt to read again.  It will return -1, even if a  
subsequent attempt to read would succeed.  In fact by adjusting my test  
code slightly I showed that you can, after receiving -1 from Peek(), call  
Read() and get valid data.  You can also, after receiving -1 from Peek(),  
call Read() and block until more data is available.  And of course finally  
you can, after receiving -1 from Peek(), call Read() and receive -1 as the  
return value, indicating the end of the stream.

In other words, Peek() doesn't really tell you very much.  For network  
i/o, it is practically never a good idea to try to look ahead at the  
data.  You should receive the data you're ready to deal with, and not try  
to look at any data beyond that.  StreamReader exposes Peek() for some  
reason, and while I'm of the opinion that it's of limited utility even  
with non-network streams, it's obvious to me that it inherits much of the  
same problematic issues that network streams have with looking ahead  
generally.

If you are going to use Peek(), you must take into account its exact  
behavior, and based on my experiment it's clear from looking at the code  
you posted that you're not doing so.

Personally, I would avoid using Peek() altogether.  It's a poor technique  
even when it works properly, and in this case the only way to get it to  
work right is to add enough code that the call to Peek() becomes  
irrelevant anyway.  With a network stream, if Peek() returns -1, the only  
safe thing to do at that point is call Read() and find out what happens.  
Given that, you might as well just call Read() in the first place and  
forget about Peek().

I will recommend once again that you try using the code I posted earlier.  
I suspect that it will fix the problem you're dealing with, and as an  
added benefit it's a lot simpler than what you've posted so far (in your  
original message as well as later).

Pete

p.s. Another interesting thing I noticed with my test code is that the  
StreamReader tries to read from the stream any time you read from the  
StreamReader, even if it's already reached the end of the stream and  
buffered all of the remaining data.  I still haven't figured out if this  
is a bug or a feature.  Seems like the only time it'd matter is when the  
stream lies to the reader about being at the end.

Anyway, here's my test code (with Program class to execute it) (my  
apologies if there's a minor compilation error; my actual project is two  
different files, and I combined them while composing this post, so the  
exact posted code hasn't actually been through a compiler):

using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Threading;

namespace TestPseudoNetStream
{
    class Program
    {
        static void Main(string[] args)
        {
            string strData = "Now is the time for all good men to come to  
the aid of their country.\r\n" +
                "The quick brown fox jumped over the lazy dog's back.\r\n"  
+
                "We are now at the end of our data.";
            MemoryStream streamMemory = new  
MemoryStream(Encoding.Unicode.GetBytes(strData));
            PseudoNetStream streamNet = new PseudoNetStream(streamMemory,  
0.2f, new TimeSpan(), new TimeSpan(0, 0, 3));
            StreamReader reader = new  
StreamReader(streamNet,Encoding.Unicode);
            string strLine;

            Console.WriteLine("Using ReadLine():");
            while ((strLine = reader.ReadLine()) != null)
            {
                Console.WriteLine(strLine);
            }

            streamNet.Position = 0;
            reader.DiscardBufferedData();

            StringBuilder sb = new StringBuilder();

            Console.WriteLine("Using Peek():");
            while (true)
            {
                int ch = reader.Peek();

                if (ch == -1)
                {
                    // Uncomment the next line to see how reading after
                    // Peek() fails causes more data to be read
                    // ch = reader.Read();

                    if (ch == -1)
                    {
                        Console.WriteLine("Peek() returned -1");
                        break;
                    }

                    sb.Append((char)ch);
                }

                sb.Append((char)reader.Read());
            }

            Console.WriteLine(sb.ToString());

            Console.WriteLine("done!");
            Console.ReadLine();
        }
    }

    class PseudoNetStream : Stream
    {
        private Stream _stream;
        private float _fractionIo;
        private bool _fSleep;
        private TimeSpan _tsDelayMin;
        private TimeSpan _tsLengthMax;
        private Random _rnd = new Random();

        public PseudoNetStream(Stream streamBase, float fractionIo,  
TimeSpan tsDelayMin, TimeSpan tsDelayMax)
        {
            if (streamBase == null)
            {
                throw new ArgumentNullException("streamBase must be  
non-null");
            }

            if (fractionIo < 0 || fractionIo > 1.0f)
            {
                throw new ArgumentOutOfRangeException("fractionIo must be  
between 0 and 1, inclusive");
            }

            _stream = streamBase;
            _fractionIo = fractionIo;
            _tsDelayMin = tsDelayMin;
            _tsLengthMax = tsDelayMax - tsDelayMin;

            _fSleep = _tsDelayMin.Ticks > 0 || _tsLengthMax.Ticks > 0;

            try
            {
                Console.WriteLine("input stream has "  
+ streamBase.Length.ToString() + " bytes.");
            }
            catch (NotSupportedException)
            {
            }
        }

        public override bool CanRead
        {
            get { return _stream.CanRead; }
        }

        public override bool CanSeek
        {
            get { return _stream.CanSeek; }
        }

        public override bool CanWrite
        {
            get { return _stream.CanWrite; }
        }

        public override void Flush()
        {
            _stream.Flush();
        }

        public override int Read(byte[] buffer, int offset, int count)
        {
            int cbRead;

            if (_fractionIo > 0)
            {
                cbRead = Math.Max(1, (int)(count * _fractionIo));
            }
            else
            {
                cbRead = Math.Max(1, (int)(_rnd.NextDouble() * count));
            }

            if (_fSleep)
            {
                TimeSpan tsDelay = _tsDelayMin + new  
TimeSpan((long)(_rnd.NextDouble() * _tsLengthMax.Ticks));

                Console.WriteLine("--> Delaying read of "  
+ cbRead.ToString() +
                    " bytes (originally " + count.ToString() + " bytes),  
by " +
                    tsDelay.ToString() + " <--");

                Thread.Sleep(tsDelay);
            }

            cbRead = _stream.Read(buffer, offset, cbRead);

            Console.WriteLine("--> actual read length: "  
+ cbRead.ToString() + " bytes <--");

            return cbRead;
        }

        public override void Write(byte[] buffer, int offset, int count)
        {
            _stream.Write(buffer, offset, count);
        }

        public override long Position
        {
            get { return _stream.Position; }
            set { _stream.Position = value; }
        }

        public override long Seek(long offset, SeekOrigin origin)
        {
            return _stream.Seek(offset, origin);
        }

        public override long Length
        {
            get { return _stream.Length; }
        }

        public override void SetLength(long value)
        {
            _stream.SetLength(value);
        }
    }
}

We already have that in Read - it's a case of creating a
MemoryStream-like type which lets you state how the stream should
respond in various cases.

I should stress that this class wouldn't be useful as a *production*
class - it would be a class to help *test* code. Basically a stub, or
at least somewhere between a stub and a mock.

Well, it's handy to be able to check whether a program behaves
correctly in the face of IO errors.

I don't know - I'm quite happy with its behaviour for most of the time.
I always assume that *any* stream may return less bytes than have been
requested, even if there's more data on its way.

What other problems do you have with NetworkStream?