Re: [boost] Re: Re: Re: Re: Re: (Another) socket streams library

From: Iain K. Hanson (ikh_at_[hidden])
Date: 2005-04-27 19:34:05

On Wed, Apr 27, 2005 at 07:34:25PM +0200, Giovanni P. Deretta wrote:
> Iain K. Hanson wrote:

[snip]
> 
> Yes, the buffer is absolutely necessary, but does not need to be 
> contiguous in memory: it can be composed from smaller buffers.
> This smaller buffers can be used by a streambuffer. When the 
> streambuffer detects that the buffer is full, it does not immediatelly 
> write it out, it simply queues it in a buffer vector and gets a new 
> empty buffer.  When the size of the buffer vector reaches an ideal size 
> (MSS or MTU), it is written using vectored io (writev or writemsg).
> This way the streambuffer user does not need to be aware of buffer size 
> requirement.

Hi Giovanni, Yes i am aware of scatter / gather but I was simplifying in order
to get my point across. However, even in scatter / gather each individual 
buffer must be contigous. The idea of using a concept is that there can be 
more that one class that implements the concept so not just vectors but
also boost::array and unsigned char [], and there may be other containers.

BTW char, signed char, and unsigned char are 3 different types and only unsigned
char satisfyies the requirements for networking portably.

I'm not at all sure that you can absolve the user from buffer size concerns
but I also don't know that your wrong. I don't personally have a strong 
interest in an iostream interface or rather III have not until this recent 
discussion. 

I always assumed that the critisisims of an iostream interface for sockets
were valid. As I have thought about it more I am inclined more to the view
that the overhead could be constant and that is interesting.

> A simmetric aproach can be used for reading.
> This is expecially useful if you read data from disk and want to write 
> it out after appending a small header, if you don't want to copy header 
> and file data on a single buffer you have to do two writes OR you use 
> vector io.
> 
> This boils down to one single rule: when reading read as much as 
> possible (i.e. untill we would block), when writing write as much as 
> possible.  If user code wants to see writing and reading as small 
> operations they are free to do so.
> This rule is also usefull when using edge trigered readiness 
> notification APIs (epoll and kqueue in edge trigered mode).

Agreed. But I have great difficulty in understanding why anyone would want 
to do edge triggered epoll / kqueue / dev/poll.

regards

/ikh