Re: how to handle multiple-message-in-same data-buffer (async programming)
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Wed, 19 Mar 2008 11:38:25 -0700
On Wed, 19 Mar 2008 05:35:46 -0700, <asharda@xxxxxxxxxx> wrote:
In async programming model, if two messages are received exactly at
the same time by the server, how does it handle it? (is it on separate
threads?).
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...
Yes, there is a content-length field that accurately describes the #
of bytes in the message (similar to a http-post that will have header-
fields consisting of content-length and other fields, and then body
consisting of the message).
I can write a program/method to check if there is more than 1 instance
of content-length and then filter/process accordingly. But isnt there
a more better way to handle scenarios where-in two messages are
received in the same buffer?
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
Thanks.
RS
.
- Follow-Ups:
- References:
- Prev by Date: Re: Assembly.LoadXXX methods and GAC
- Next by Date: Re: Capture text sent to a printer to a file.
- Previous by thread: Re: how to handle multiple-message-in-same data-buffer (async programming)
- Next by thread: Re: how to handle multiple-message-in-same data-buffer (async programming)
- Index(es):
Relevant Pages
|
