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

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:
> 
> [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