Sockets and Serialization

[John Hoffman]

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

[Stelrad Doulton]

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

"John Hoffman" <John Ho*****@discussions.microsoft.com> wrote in message
news:BC**********************************@microsof t.com...

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

[Stelrad Doulton]

.......yeah. pretty much what you wanted to avoid ;-)

"Stelrad Doulton" <___@____.com> wrote in message
news:Qe**************@newsfe1-gui.ntli.net...

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

"John Hoffman" <John Ho*****@discussions.microsoft.com> wrote in message
news:BC**********************************@microsof t.com...

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

[John Hoffman]

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...

"Stelrad Doulton" wrote:

.......yeah. pretty much what you wanted to avoid ;-)

"Stelrad Doulton" <___@____.com> wrote in message
news:Qe**************@newsfe1-gui.ntli.net...

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

"John Hoffman" <John Ho*****@discussions.microsoft.com> wrote in message
news:BC**********************************@microsof t.com...

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