Re: sockets library

From: dmoore99atwork (dmoore_at_[hidden])
Date: 2001-12-20 13:04:47

.......

> 
> I'm usually a Boost lurker but this one is close to my heart.
> 
> I understand and accept the arguments made about not basing a 
sockets layer
> on streamio, streambuf and friends.  I think Ross is right.
> 
> However, I can also appreciate the convenience of using sockets 
like any
> other stream.
> 
> Would it not be possible to write two libraries?
> - the first would be the non stream based, efficient library that 
Ross and
> others would like to see.
> - the second would build on top of this and provide the stream 
based i/o.
> 
> Yes, there would be a cost in terms of performance for the stream 
stuff but
> this would be left user-developer to decide.
> (If you are doing lots of text based i/o you probably prefer 
streams, and if
> your doing a lot of text based i/o efficiency probably isn't your 
number on
> concern.)
> 
> Just an idea.
> 
> allan

I wholeheartedly second this approach...  Here's my summary of what 
I've read so far, as well as a little bit of my own input

First and foremost, deliver a typesafe c++ socket object family for 
DGRAM and STREAM sockets.  Think the ACE family without every 
permutation of IRDA, domain sockets, "file sockets", etc. under the 
sun.  Highlights would be objects for name resolution, the 
acceptor/connector pattern (the best idea in the whole library, imo), 
and a container for "select" type operations.

Then, extend things in two directions.  

One would be performance directions, looking to non-blocking and 
overlapped operations.  Most realistic overlapped I/O would probably 
make good use of the Boost threads library for thread pool based 
architectures ala Win32 IO Completion Ports or Solaris asynch_io.  
ACE is again a good model for some ideas here, I think.

Second would be a streams interface (binary and character based).  I 
think a streambuf based on BLOCKING socket operations would be pretty 
straightforward, and the streams on top of this could leverage 
existing implementations.  

Streams & Streambufs built on non-blocking or overalpped i/o 
mechanisms would require much more thought and design.  Call this 
phase III.

Dave