Re: [boost] [Ann] socketstream library 0.7

From: Maxim Yegorushkin (e-maxim_at_[hidden])
Date: 2005-06-13 02:37:26

On Sun, 12 Jun 2005 19:25:30 +0400, Jeff Garland  
<jeff_at_[hidden]> wrote:

[]

> Yes, I've see it work quite well in real programs.  It works something  
> like this:
> 1) Protocol header had message type/size at top of packet
> 2) Socket core ensured a full read of message into a std::streambuf
> 3) Application layer received streambuf with message type callback
> 4) Application would create 'message object' based on type
> 5) Used i/o streaming/serialization to read message object from streambuf
>
> Simple and clean.  Socket core doesn't really care about message content  
> -- as it should be.  Application layer does that -- has the option of  
> using
> iostreams or parsing from the buffer directly.  BTW, some of the message
> formats are binary using a different serialization format adapter  
> against the streambuf.

... And too slow. You have one data copy from kernel into the streambuf,  
and another one from the streambuf to the message object. The same is for  
output: message -> streambuf -> socket. This is unacceptable, at least for  
the kind of software I build.

For example, I had a router which used a TCP binary protocol. Each message  
is prefixed with 4 byte length, so I read the 4 bytes, resized a  
std::vector<char> for the message length, and then read the message into  
the vector. After profiling the router under heavy load it turned out that  
30% of user time was spent in guess where? In zeroing out memory in  
std::vector<char>::resize(). And you are talking about data copying here...

-- 
Maxim Yegorushkin