1

I am Sending Serialized large Image Object over UDP Socket.When I write all received bytes in Memory stream and pass the memory stream object for deserialization it throws an exception No assembly ID for object type 'ImagePacket'.

Receiver End Code:

                 ImageStream = new MemoryStream();

                while (AccumulatingBytes <= TotalSizeOfComplexObject)
                 {

                  byte[] Recievedbytes = UdpListener.Receive(ref RemoteEndPoint);

                  ImageStream.Write(Recievedbytes, 0, Recievedbytes.Length);

                   AccumulatingBytes += Recievedbytes.Length;
                 } 


                  ImageStream.Position = 0;

                    imagecontainer = (ImageContainer)bformater.Deserialize(ImageStream);//Here the Code Segment Breaks and Exception thrown
Samie
  • 83
  • 2
  • 11
  • Is ImagePacket your own class? – Marc Gravell Jan 23 '12 at 13:02
  • Yes ImagePacket is my own class – Samie Jan 23 '12 at 13:03
  • An [MSDN post](http://social.msdn.microsoft.com/Forums/eu/netfxremoting/thread/976b61ca-443f-4e6c-86d9-521542c4c8c8) suggests this can relate to stream corruption. Before going any further, PLEASE check that the bytes you received are identical to the bytes that were sent. In particular (as I already mentioned once) UDP doesn't care much about accuracy... if you want accuracy, use TCP. – Marc Gravell Jan 23 '12 at 13:04
  • I was using TCP before.Now I m transforming it over UDP as i was getting Latency issues in TCP.How to avoid stream corruption in UDP? – Samie Jan 23 '12 at 13:07
  • I edited my example to illustrate – Marc Gravell Jan 23 '12 at 13:14

1 Answers1

1

I suspect the problem here is simply: you are using UDP like it is TCP. UDP is packet based, but a: doesn't guarantee that the packets will arrive in order, and b: doesn't guarantee that packets won't be dropped or duplicated.

I fully expect you have some out of order. If you are sending multiple messages, it is also possible some were dropped, and you've included a few from the next message.

To use the network the way your code wants to use it: use TCP. Otherwise, the responsibility for making sense of out-of-order, dropped and duplicated packets is entirely yours. This could be, for example, by adding a sequence number to the packet, and keeping track of what has been received - re-ordering them as necessary, dropping duplicates, and re-requesting any that died en-route. Basically, re-writing everything that TCP adds! Unless you have a very specific scenario, there's a good chance that the TCP stack (with NIC and OS level support) will do a better job of this than you will.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • As a side-note: UDP makes sense when **speed** is key, and you'd rather have the latest data even if that means you ignore some that failed; however, you are using it as a stream - when the data is a stream, I'd look at TCP first. – Marc Gravell Jan 23 '12 at 13:15
  • I am intended to use Real Time Transport Protocol with conjunction of UDP as majority of implementations are done on UDP.see ref http://en.wikipedia.org/wiki/Real-time_Transport_Protocol. – Samie Jan 23 '12 at 13:16