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
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?
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk