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