Re: [boost] (Another) socket streams library

From: Giovanni P. Deretta (lordshoo_at_[hidden])
Date: 2005-04-27 20:29:33

Iain K. Hanson wrote:
> 
>>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

Of course the single buffers are contiguous.  The point here is that you 
don't need to flush every time a single buffer is full.  You keep 
filling buffers until you explicitly flush the stream (std::endl).

> 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.
>

I do not see how this is related with the problem.  Using multiple 
buffers is an implementation detail that let the user be oblivious of 
transfer size optimizations.

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

Right, I didn't think of this.

> 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. 
> 

Neither do I, but i think that once you have working underlying 
networing framework framework, it will not be hard to fit iostreams on 
top of it.

> 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.
> 

Well why not, it might actually simplify some code.

--
Giovanni P. Deretta