0

Im not sure why this is throwing the error End of stream encountered before parsing was completed. I looked at this link but nothing on there fixed the problem in my case. I used break points to find the exact point it throws the error witch is

       Console.WriteLine("Message from client ");

Thanks in advance

   if (stream.DataAvailable)
   {
       byte[] buffer = new byte[10024];
       int byteCount = stream.Read(buffer, 0, buffer.Length);
       byte[] inBytes = new byte[byteCount];
       for (int counter = 0; counter < byteCount; counter++)
           inBytes[counter] = buffer[counter];
       BinaryFormatter formatter = new BinaryFormatter();
       MemoryStream memory = new MemoryStream();
       memory.Write(inBytes,0,inBytes.Length);
       object message = (object)formatter.Deserialize(memory);
       Console.WriteLine("Message from client ");
       memory.Close();
   }

Edit* this was my bad nothing was wrong with the actual code here i made the mistake on the client end. i used Encoding.ASCII Instead of a binaryformatter.

Community
  • 1
  • 1
Shredder2500
  • 1,065
  • 2
  • 11
  • 26

2 Answers2

5

Well, you're assuming that a single call to stream.Read is going to read all of the data. That's almost always a mistake, especially if it's a network stream.

Is there any reason you're not just calling formatter.Deserialize(stream) in the first place?

Austin Salonen
  • 49,173
  • 15
  • 109
  • 139
Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • thats how i had it first, changed it to try and debug the code, aslo if i do that since its in a loop it just keeps throwing the error over and over, and when its like it is now its only thrown once. – Shredder2500 Jun 20 '12 at 18:00
  • @Shredder2500: What's the loop? You haven't really given enough context here. If these are "messages" from the client, do you have any sort of delimiter for the message, or do you know the length? Just hoping that you get exactly one message (and only one message) in a single `Read` call is a very bad idae. – Jon Skeet Jun 20 '12 at 18:06
  • it just a while loop that loops forever although it doesn't need to right now. right now im just sending one string over. – Shredder2500 Jun 20 '12 at 18:12
0

this was my bad nothing was wrong with the actual code here i made the mistake on the client end. i used Encoding.ASCII Instead of a binaryformatter.

Shredder2500
  • 1,065
  • 2
  • 11
  • 26
  • I disagree... the code really is wrong... you **must** check you've got a full frame before you try and process it – Marc Gravell Jun 20 '12 at 19:34
  • well the code itself is not finished, the point of the question though was what was causing that error, witch was nothing in that code. right now i was just testing to make sure it is getting data. some of the code in there was just to try and see what was wrong with it. for one its back to just using the formatter instead of the buffer and bytes. And i am adding the check now. – Shredder2500 Jun 20 '12 at 20:04
  • @MarcGravell how do you check if you've got a full frame, i have the same issue?? – Smith Mar 22 '15 at 06:07
  • @Smith you need to define frames in your protocol. In text protocols that might be the mere fact of an end-of-line (cr/lf). If binary protocols it is common to prefix the date with something that tells you how much data is in the next frame. – Marc Gravell Mar 22 '15 at 12:17
  • @MarcGravell any tutorial , reference or guide on how to implement this? – Smith Mar 22 '15 at 18:23
  • @Smith text or binary? – Marc Gravell Mar 22 '15 at 19:07
  • @Smith that's easy, then; you just need to define what an end-of-message marker will be (10? 13? 0? 3? 4?) and buffer bytes until you see that byte. Once you've done that, decode all the buffered bytes in one go via an `Encoding`. Note that you might be tempted to buffer *characters*, but this is a common cause of error: the incoming data is not guaranteed to be entire characters, unless the data is ASCII. For any other encoding, you could get have a character in one `Read`/`Receive` , and the other half in the next. – Marc Gravell Apr 03 '15 at 09:17