On Fri, 2005-04-22 at 12:06 -0300, pedro.lamarao@mndfck.org wrote:

Iain Hanson wrote:

[SNIP]

...

A buffer concept is absolutely essential for TCP. Without it you will run into delays with Nagle, delayed ack and slow start all combine-ing. Yuk!

Streambuf makes sense for the iostream concept. For lower layers the buffer concept needs to be a model of contiguous container. Iterator type can only be guessed at because I don't know what goes on inside the 'C' socket lib or the kernel but first guess would be forward iterator.

Well, if you think about it, the streambuf *is* the lower layer buffer concept (unless you consider ir a buffer over the "kernel buffer"). The methods it offers are simple: get char, put char, and the like.

Exposing a "socket" class is a requirement only if the proposed library wants to try to interface with old, "hybrid" code, provide the possibility for some kind of "extension" I really can't think of. A C++-only library could just not have a "socket" class, or consider it "private", and expose as the most basic thing the stream buffer. If you don't need the buffering itself, call pubsetbuf(0, 0).

I agree that the socket class may be private detail for an iostreams implementation but I do not agree that all network i/o should be done this way. I don't think that iostreams as a model works well for packet protocols. BTW do you use path MTU or MSS to set your streambuf size? /ikh