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

From: Darryl Green (Darryl.Green_at_[hidden])
Date: 2003-02-16 22:42:03

> -----Original Message-----
> From: Jeff Garland [mailto:jeff_at_[hidden]]
> 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.

I don't know exactly what you mean by "non-trivial sever" and what you
get from ACE/expect not to get from Boost.Socket that a non-trivial
server requires? Is this a maturity of implementation issue or a
functionality one? We managed to discard ACE (there was a fair bit of it
we didn't want/need and some that needed fixing) and use implementations
of the reactor, connector and acceptor patterns based on modern C++
facilities. This is used in servers that may or may not be considered
"trivial" but certainly couldn't be implemented using a simple
thread-per-connection model.

> 
> 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.

Fair enough.

> 
> > 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.

Isn't multiplexing a form of callback interface (reactor pattern)? Or do
you mean async-io (proactor)? I'd definitely consider trying to
implement a portable async-io library to be a step too far at this
stage.

> 
> 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.

I tried to discuss this here before - maybe I should put stuff up on the
wiki instead? The lib I talked about above does precisely that. Given
the ubiquitous boost shared_ptr and function and a bit of design
something a less ugly than ACE pops out fairly easily. We were inspired
by and initially used boost::signal but found we didn't get any benefit
from it in this particular case.

> 
> Jeff
> 
> Jeff
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost