Socket issues with EndReceive

[Ken Foster]

I have a Socket based application using the asynchronous Sends and Receives
of the Socket class. I send out XML strings using BeginSend/EndSend from a
client end point, the server side does a BeginReceive/EndReceive.

I knew a message could be split up between Receives and I look for an end of
message marker (and continue receiving if not there) before processing the
complete message. However I was told (on this board I think) that I would not
have to deal with multiple messages in one packet. That is, I wouldn't get
[Message1]<EOM>[Message2] in the same Receive Buffer.

But that is exactly what I'm seeing. I can code for this if thats to be
expected, but I wanted to know if this is a sign of a bug, or this is really
what should/could happen with asynchronous Sockets.

Should I assume that a Receive on a given socket from a given RemoteEndpoint
is not separate and distinct messages but a continuous message stream where
one message could be broken up across multiple packets AND multiple messages
(or parts of messages) may show up in one packet?

Thanks,
Ken

[Joep]

Yep, it is a stream and not a bug.

[Ken Foster]

Okay, so within one socket channel (a fixed localEndPoint/remoteEndPoint)
multiple sends could show up back to back in the same receive buffer? Good to
know, I'll code for that.

Is this just for one socket connection though? I have one listening Port on
a server that several clients connect to. Each client connection gets its own
BeginReceive call. They won't overlap right? The messages could be connected
together in a single stream, BUT ONLY if those messages originated from the
same client end point?

Sorry if that seems overly nitpicking, but i've heard conflicting answers
and just wanted to make sure I have the facts straight.
"Joep" wrote:

Yep, it is a stream and not a bug.

[William Stacey [MVP]]

> Okay, so within one socket channel (a fixed localEndPoint/remoteEndPoint)

multiple sends could show up back to back in the same receive buffer? Good to know, I'll code for that.
yes. When you read the stream you could get 1 byte or more, there are no
message boundaries like udp. You define your own message boundaries with
tcp stream. Also note I have yet to confirm this myself, but have heard a
report from someone that sounded credible that Async Send may not send all
bytes as the doco says for connection-oriented socket, so you should check
for that as well. Also, with Async socket calls, you can get the callback
for send2 before the callback for send1, which "may" effect you dramatically
depending on your logic.

Is this just for one socket connection though?

Yes as each client has own socket on your listener side so they the streams
don't effect each other.

--
William Stacey, MVP

[Ken Foster]

Good to know about the possible break up of a send, that should be simple
enough to code for defensively.

Could you elaborate on what you mean about send2 before send1? Do you mean
the message sent from send 2 will (in its entirety even if across multiple
receives) arrive before the message from send1? If thats the case we're okay,
we have synchronous and asynchronous sends, the developers are instructed on
when to use one vs. the other, if timing is an issue, synchronous is to be
used.

But if you mean a message stream may arrive mixed up, that is a bigger issue.
"William Stacey [MVP]" wrote:

Okay, so within one socket channel (a fixed localEndPoint/remoteEndPoint)
multiple sends could show up back to back in the same receive buffer? Good

to

know, I'll code for that.

yes. When you read the stream you could get 1 byte or more, there are no
message boundaries like udp. You define your own message boundaries with
tcp stream. Also note I have yet to confirm this myself, but have heard a
report from someone that sounded credible that Async Send may not send all
bytes as the doco says for connection-oriented socket, so you should check
for that as well. Also, with Async socket calls, you can get the callback
for send2 before the callback for send1, which "may" effect you dramatically
depending on your logic.

Is this just for one socket connection though?

Yes as each client has own socket on your listener side so they the streams
don't effect each other.

--
William Stacey, MVP