Re: [Boost-users] message based TCP protocol?

From: Cliff Green (cliffg_at_[hidden])
Date: 2007-05-22 18:14:43

On Tue, 22 May 2007 15:52:58 +0200
  "Radu-Adrian Popescu" <rpopescu_at_[hidden]> wrote:
> My 2c: I've found that the easiest way to do this is to 
>use blocking
> reads. I'm not sure whether you can get any performance 
>benefit by not
> using blocking reads; I kind of doubt it. Also using 
>blocking reads
> simplifies things _a lot_, since all you have to do is:
> 1) read a known number of bytes that tells you how many 
>more you have to read
> 2) read as many bytes as resulted at step 1)
> 

With Asio (I'm looking at 0.3.8rc3), async reads for this 
(common) form of "message protocol" is just as easy as 
doing blocking reads. Specifically, the "asio::async_read" 
functions specify a "completion_condition", which defaults 
to the protocol mentioned above. (I like the 
"completion_condition" design, since it allows an easy 
override of message boundary logic, while defaulting to 
the common cases.)

Even if Asio didn't provide nice default handling of 
"message boundaries", it's pretty easy to write the logic 
yourself in a non-blocking design, whether using an async 
(proactive) or reactive model.

And I think you *would* get performance benefits using the 
async_read capabilities, or at the very least concurrency 
benefits, specially with large messages. As a real-world 
use case, I wrote a networking infrastructure library for 
a project that typically sent messages between 1K and 8K 
bytes in length, but at certain times would send messages 
dozens (or hundreds) of megabytes long. Having the 
application (or a thread within the app) block while 
collecting all of the data for a single message was 
unacceptable. The library multiplexed all network reads 
and writes transparently and concurrently for the 
application (across multiple connections). Note that the 
"concurrency" I'm mentioning here is not threading 
concurrency, but IO multiplexing (between multiple sockets 
/ connections) concurrency (it had the same general event 
multiplexing model as Asio does).

Cliff