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