From: Iain Hanson (Iain.Hanson_at_[hidden])
Date: 2005-04-22 11:41:18
On Fri, 2005-04-22 at 12:06 -0300, pedro.lamarao_at_[hidden] wrote:
> Iain Hanson wrote:
> > 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
BTW do you use path MTU or MSS to set your streambuf size?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk