It depends on what you mean. But generally, if it's _not_ on separate
threads, then the recipient (whether server or client) is by definition
_not_ receiving two messages exactly at the same time. A single thread
can only process a single thing in a given moment.
The other issue is that when using TCP there is no such thing as a
"message", except as your own application code defines it. The .NET
classes (Socket, TcpClient, whatever you're using) won't know anything
about a "message".
Your question is somewhat vague, because it's not clear what you mean by
"exactly at the same time". There are at least three different ways to
read the question.
If you're talking about receiving two messages that were sent on the same
connection by the same sender, then the only "same time" you could be
talking about is that they may be combined into a single chunk of data to
be received by your server. But in that case, by definition that single
chunk will be processed by a single thread.
If you're talking about receiving two messages that were sent over two
different connections (e.g. two different senders, or the same sender
using two different connections), then the messages will be separated
according to the connection. Two different threads could in fact be
processing completed i/o on two different connections, but in that case
there should be no confusion because each connection will have its own
context (you should be passing a per-connection data structure when you
post the receive by calling Socket.BeginReceive()).
I hesitate to even describe the third scenario, since I doubt it applies
to you, and it might only confuse the issue. But for completeness's sake,
I'm including it anyway (but don't worry if you don't "get" it)...
Finally, I don't think this is what you're talking about, but you could be
describing a situation where you've posted more than one receive on a
connection at a time. This is a common technique in high-performance IOCP
servers, but it's fairly advanced and not something most people do on
their first try. But for code that does this, since you've got two or
more asynchronous operations that have been started simultaneously, that
means you could have two or more asynchronous operations complete at the
same time.
So, you could have two different threads receiving data on the same socket
at the same time. But that data is not necessarily going to be grouped as
individual "messages" between the two threads. The only thing you're
guaranteed (as I wrote before) is that the bytes received will be in the
exact same order as they were when they were sent.
That order is defined, by the way, according to the order in which you
posted the asynchronous receives (e.g. you called Socket.BeginReceive()).
The i/o completion may be posted out of order, but the data is guaranteed
to be in the right order in your buffers. This means that before you
start processing a chunk of received data, you need to check to make sure
you've completed receives on all of the buffers that were posted before
the one you're operating on currently. If you haven't, then you need to
set aside the current buffer (in an ordered queue, for example) and wait
to process it until you've seen the completion for previous buffers.
Now, all of this only applies if you post more than one receive on a given
socket at a time. IOCP allows this, and thus .NET inherits it as well.
But if you only call BeginReceive() once and don't call it again until
you've called EndReceive(), then obviously you will never be notified for
the completion of i/o on that socket in more than one thread at a time.
Now as far the rest of your post goes...
If the "content-length" field describes the number of bytes for that
transmission, then you should just use that number of bytes to determine
where that message ends and the next one begins.
If it doesn't describe the number of bytes for that transmission, then
yes...you seem to be left with the option of using the "content-length"
field (assuming it's the very first thing in a transmission) as the
delimiter for the message. This assumes, of course, that the rest of the
data in a message will never contain the text "content-length". This is
definitely not the case for HTTP, which you have compared your own
situation to, so this might not work.
Once again, there is no way to say for sure what you need to do until you
describe more precisely what is actually being sent and how you're
expected to process it.
Pete
