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