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
> 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
> > sure the design is truly flexible. I recommend Apple's
> > 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
> > 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?
> > At the very end of it, network programmers should be using a
> > callback-driven interface and not have to worry about multiplexing
> > 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
> 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.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk