Reading NetworkStream blocks forever about protobuf-net HOT 5 CLOSED

Thanks for the info and patch; before I commit the patch, I just want to 
quickly look  
into how DataAvailable behaves with respect to buffering - i.e. is it likely to 
incorrectly thing it has the end of the batch, when actually some is still 
buffered 
at the client.
For info - one option for network usage is the "...WithLengthPrefix" methods 
(in the 
HEAD, but maybe not in the downloadable dll) - this sends the length of each 
batch 
first, which makes network usage very simple: it knows it is expecting <x> 
bytes, so 
it stops cleanly after <x> bytes (see the QuickStart project for an example).

Thanks again - I may well end up applying that patch (once I have checked how 
it 
behaves: I'll be honest - raw sockets isn't my usual thing...).

Marc

I've done some checking, and general consensus is that DataAvailable cannot be 
used 
(robustly) to prove that the batch is complete; it simply indicates that the 
receive 
buffer is empty, which isn't the same thing: if this happens to fall at the 
point  
between fields, then data corruption will occur.

The recommendation given was to use a length-prefix if working with batches, 
which is 
what the QuickStart already does. Of course, if you are just sending one batch 
you 
can serialize and Close() the stream, which will work just as well - but if you 
want 
a dialogue over the socket it should use a length prefix.

If I've got it wrong, please say...

Thanks for looking into it.  I didn't try the WithLengthPrefix methods, as it 
wasn't
in revision 164, and i just updated to 171 to see if the bug I was experiencing 
was
fixed in the newer version...  Tested again with these methods and it works.

You are right, of course - it [a conversation over a NetworkStream] simply 
didn't 
work in r164, which I found when putting together the quick start example; 
these 
methods were added exactly to fill this gap.

Any other problems, let me know.

Marc