Sockets and Serialization

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello, I've got a client server app that passes C# objects back and forth
using TCP/IP Async Sockets and Serialization. Works great in the lab, but
when I try it on a the internet or through a slower dial-up, the receive
callback is not always receiving what I wrote. Analyzing this I see that
there is not always a one to one send data/receive data situation. The data
seems to come over but comes over in multiple receive callbacks. Since I am
passing C# objects, when I go to deserialize them, they error out. (usually
with a end of stream error).

The question is, how do I get the BeginReceive to only callback when all of
the data is there and not chunk it up?? I would hate to have to gooberize the
code to detect short packets and paste them together on the other end.

TIA, John Hoffman
 
I've just dealt with this myself though I wanted to define the end of a file
or message but I think you can employ a similar strategy. Are you doing the
serialising yourself or using the Binary / SOAP formatter? After many
attempts to come up with a solution that worked on all networks I ended up
taking control of serialisation and wrapping each transaction (in your case
object) in an XML-esque tag for ease of parsing at the rx end. This has the
added advantage that any meta information can be added to this tag if you
find that you need it.

Upon each EndRecieve I scan backwards from the end of the rx'ed bytes
looking for ">" if I don't find it I copy the bytes into a new array and
stick it on a queue and go back to BeginRead. If however I do find it then I
check the preceding bytes match </object> (you may have to peek the previous
buffer on the queue if you have received a very few) should it transpire
that the end has been reached dequeue all the buffered buffers (!) into a
memorystream, than add the last buffer and raise your event. Note also that
I used a ThreadPool thread to raise this event so that I could get back to
BeginRecieve ASAP rather than waiting for a potentially long running event
handler to complete.

HTH
 
Thanks for confirming this. I ended up wrapping the object. Still hard to
believe that the Socket class can't be setup to do a send/receive on a one to
one basis...
 
Back
Top