Hello all I met some of you on the list at this years ACCU conference in Oxford. However, I forgot to ask something I might supply to boost. I have a long experience with writing and using iostream adapters for TCP-sockets (in 24x7 production servers written in C++). A quick look at boost seems to me that this part of IO is lacking. My current solution is not yet fit for inclusion into boost, because it is still using "legacy" C++ and requires some infrastructure from another foundation library (mine :-). However, I'd like to modernize that library and the surrounding MT-server-framework in the future. If such a work (sockt-iostream) could go into boost, I would be happy to use boost as a new foundation for my framework. I'd like to hear, a) if there is interest in iostream for sockets b) if there is already a solution pending for inclusion (to review it) c) if there are people working on it who I might join Thanks for giving me some answer encouring me to work on that topic...:-) Yours Peter. -- -- Peter Sommerlad Erlenstrasse 79 CH-8832 Wollerau tel +41 1 687 44 74 fax +41 1 687 44 71 mobile +41 79 432 23 32 mailto:psommerlad@hispeed.ch
Peter, On Thu, May 05, 2005 at 04:42:33PM +0200, Peter Sommerlad wrote:
I'd like to hear, a) if there is interest in iostream for sockets b) if there is already a solution pending for inclusion (to review it) c) if there are people working on it who I might join
Have you read the archives? (search on "socket") There's been a lot of discussion, and I think some work done, but stalled. On Unixy systems, of course, there's not much difference between a socketbuf and a filebuf (presuming you can make one from a file descriptor) or an aftermarket fdbuf or stdiobuf (if you can't). On systems that don't have file descriptors, though, it is essential, and as a Boost component it makes sense as a portability aid and a convenience even for the Unixy folks. Besides the regular streambuf operations, it would need ways to open various sorts of connections, to set various modes and flags, to discover more about why it returned EOF, and to support creative buffering schemes (e.g. auto-grow, mmapped buffers for zero-copy networking, seeking within still-buffered text and controlling when to toss already-read text, and peeking at what's in the buffer). Then there's non-blocking sockets... (I don't know what of the above has already been discussed, I just rejoined after a long hiatus.) Nathan Myers ncm@cantrip.org
On 5/5/05, Nathan Myers <ncm@cantrip.org> wrote:
(I don't know what of the above has already been discussed, I just rejoined after a long hiatus.)
Oh there has been a LOT of discussion in the past month or so. I'm not sure there is 100% consensus on this, but my understanding is that a Boost.Sockets implementation would provide interfaces at several different layers, and iostreams would be at one of the higher levels. Here's a direct quote from Iain Hanson who named/categorized the layers: Iain K. Hanson wrote:
I created the layers concept for the C++ Networking boost library.
The layers I defined are: Layer 1 :- Light weight wrappers arround predominantl BSD socket concepts. Layer 2 :- Acceptor, Connector, Reactor, and Svc_Handler concepts ala ACE. Layer 3 :- An optional iostreams interface if desirable? Layer 4:- Applications layer - includes ftp, telent, http/s And user applications
-- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
On 5/5/05, Nathan Myers <ncm@cantrip.org> wrote:
(I don't know what of the above has already been discussed, I just rejoined after a long hiatus.)
Oh there has been a LOT of discussion in the past month or so.
And we are relaxing right now a bit from these discussions. ;-)
I'm not sure there is 100% consensus on this, but my understanding is that a Boost.Sockets implementation would provide interfaces at several different layers, and iostreams would be at one of the higher levels.
I agree that this seems to be the only concensus we have so far - please see the package diagram at http://www.highscore.de/boost/net/packages.png which should help to understand the status quo. It is quite minimalistic but anything else is still under heavy discussion. One of the next steps is to make sure that each package follows clear goals. This should help to understand what kind of functionality should be provided by each package. Boris
[...]
participants (4)
-
Boris -
Caleb Epstein -
Nathan Myers -
Peter Sommerlad