RE: [boost] Re: Sockets - what's the latest?

From: Jeff Garland (jeff_at_[hidden])
Date: 2003-02-14 12:55:09

> On Friday, February 14, 2003, at 08:38 AM, Jeff Garland wrote:
> > So in summary, I think we should focus the Boost.Socket effort
> > on what is currently described as 'level 1 - OS platform layer'
> > and 'level 2 - basic connectivity layer' leaving multiplexing
> > for later.  I'm sure this will be controversial with some, but
> > it seems to me that this is the only reasonable approach for a
> > boost library daring to tread into a complex domain.
> 
> I disagree.  By failing to provide support for multiplexing, we limit 
> ourselves to clients and servers small enough to follow the 
> one-thread-per-connection approach.  

Yep, but it is a much bigger domain than being served now...

> Multiplexing is absolutely essential for writing even moderately 
> complex servers.  Unless you're saying the user could mimic 
> multiplexing by manually looping through a vector of non-blocking 
> sockets, polling for activity.  That would work, but I still say 
> that at the very least multiplexing should be worked into the 
> design, perhaps implemented as a simple looped poll at first, 
> then done correctly later.

I agree that multiplexing has to be in the design thoughts and
ultimately part of boost, but I worry it will be too much 
to deliver, test, and review in the first pass.  And,
I see no way I would use Boost.Socket for any non-trivial
server in the near future b/c there is no way it will have
all the elements provided by something like ACE to support
server development.

That said, I would love to see the multiplexor design 
pushed forward, but not at the expense of porting, testing,
and documenting the socket core.

> Another thing is I think it is important to get at least one 
> non-Sockets-based network API in the mix right at the beginning to make 
> sure the design is truly flexible.  I recommend Apple's OpenTransport, 
> not because it will be around much longer, but because it is quite a 
> bit different from Sockets, and in order to support it we will have to 
> think outside of the Sockets domain.  Particularly with issues like 
> multiplexing, this would put into perspective just what needs to be 
> done, rather than assuming we should just provide an analog for 
> select() and be done with it.

Is there a reference you can add to the Wiki?

http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/References

> At the very end of it, network programmers should be using a 
> callback-driven interface and not have to worry about multiplexing at 
> all, but I agree that for now a third layer should be deferred until 
> the basic groundwork has been laid out.

I believe we agree :-)  BTW, I've been thinking for awhile that either
boost::function or boost::signal will provide us with core of that
callback framework that diverges from the traditional OO approach
taken by ACE and as is proposed currently on the Wiki.

Jeff

Jeff