Re: [boost] Re: (Another) socket streams library
On Thu, 2005-04-21 at 19:30 -0700, Jeff Garland wrote:
I notice we don't have a buffer concept in any of our net/socket writeups on the wiki. I think that's a big omission. I also wonder if the abstraction doesn't already exist --> std::basic_streambuf. Let the socket class write into the streambuf and then you can trivially wrap a stream around it to do sophisticated i/o if you wish -- or simply pull out the raw chars....
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. /ikh
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). And, as you point out, it's useful to have an "iterator" view of the stream buffer; that's provided by std::streambuf_iterator. Together with Spirit (and an iterator adaptor to turn std::streambuf_iterator into a ForwardIterator), an interesting kind of protocol message parser and object model can be achieved, one in which you have protocol_message classes whose parser function is operator>>. I have an example irc_message class around here somewhere; I'll post it to the list (or put it somewhere) if someone's interested in this. -- Pedro Lamarão
pedro.lamarao@mndfck.org wrote:
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 streambuf is the right buffer concept for TCP sockets. I have used a 'sockstreambuf' class in the past that allows both, the data to be managed by a streambuf, as well as plug in socket- specific APIs such as all the BSD socket API. It has worked quite well, for example it allowed me to create a temporary std::istream on top of it to read out data in a 'input available' callback. FWIW, Stefan
On Thu, 2005-04-21 at 19:30 -0700, Jeff Garland wrote:
I notice we don't have a buffer concept in any of our net/socket writeups on the wiki. I think that's a big omission.
[snip] Iain Hanson <Iain.Hanson <at> videonetworks.com> writes:
A buffer concept is absolutely essential for TCP.
Agreed that it is essential for TCP.
Without it you will run into delays with Nagle, delayed ack and slow start all combine-ing. Yuk!
What are you guys aiming at? Do you mean that boost network / socket stream lib should handle TCP buffers in our user space code? A buffer may be needed for other reasons, but "delays with Nagle, delayed ack and slow start all combine-ing" and related problems are handled by the TCP implementation. Sam
Sam wrote: [SNIP]
Without it you will run into delays with Nagle, delayed ack and slow start all combine-ing. Yuk!
What are you guys aiming at? Do you mean that boost network / socket stream lib should handle TCP buffers in our user space code?
What you call "TCP buffers", if I understood you correctly, are kept inside the kernel. The point of the stream buffer in user space is to complement the buffer in kernel space, so that you minimize as much as possible the number of system calls made. You still copy the same amount of memory from user space to the kernel buffers, but the context switching has some cost; less context switching, less cost. Fine tuning the user space buffer requires much empirical study, tough. -- Pedro Lamarão
participants (4)
-
Iain Hanson -
pedro.lamarao＠mndfck.org -
Sam -
Stefan Seefeld