From: Maxim Yegorushkin (e-maxim_at_[hidden])
Date: 2005-06-13 06:59:43
On Mon, 13 Jun 2005 15:13:19 +0400, <pedro.lamarao_at_[hidden]> wrote:
> Maxim Yegorushkin wrote:
>> ... 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
>> output: message -> streambuf -> socket. This is unacceptable, at least
>> the kind of software I build.
>> For example, I had a router which used a TCP binary protocol. Each
>> 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
>> 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
> Considering the protocol of your application has built in methods for
> announcing the length of the payload, your requirement is met by the
> streambuf::sgetn(char_type*, streamsize) method, for a properly
> specialized implementation of the virtual protected xsgetn method.
> A streambuf manipulated solely by sgetn and sputn won't ever fill
> internal buffers.
> By encapsulating your protocol message inside a protocol_message object
> with proper operator<< and operator>>, you can receive and send such
> objects by directly manipulating the streambuf associated with a stream
> through stream::rdbuf().
> So you get operator semantics for free. :-)
> And perhaps even a putback area, if there's one provided by this
> particular streambuf implementation.
Sounds interesting, but I don't see how this can work well with
nonblocking sockets. You have to store how much bytes have already been
> I'll take a note of this use case, though. As soon as documentation is
> finished for my last proposal, I'll try and do some benchmarking. How
> large are your payloads, usually?
-- Maxim Yegorushkin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk