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

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

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

Jeff