Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2003-02-17 09:03:41

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

Depends on the server, CDR formatting, thread-safe queues come to mind.
There are probably a few threading things as well. Of course all of
these can be built, but spending time building this sort of
infrastructure detracts from time spent developing the actual

>Is this a maturity of implementation issue or a functionality one?

Yes, this is a huge factor. A project I worked on using ACE has been
deployed for over 5 years with no problems.

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

No question it can and should be done, and hopefully part of
> > > 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.

Yes, and even I agree it would be best to have some basic multiplexing
in an early version of the library. However, there are tremendous
platform/portability issues in multiplexing and I'm just afraid in
another 6 months we still won't be anywhere if we try to do it all.

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

Please, the Wake is currently the point of collection. And then drop
a notification on the mailing list so we'll all go and respond.


Boost list run by bdawes at, gregod at, cpdaniel at, john at