Boost logo

Boost :

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-18 13:13:47

Boris wrote:
> Michel André wrote:

> Agreed. In the beginning acceptor and connector in
> were called server and client
> until someone complained. Now I also like acceptor/connector better than
> server/client but if they remind developers of the acceptor-connector
> pattern that's no good. However I don't know any better name in the moment -
> if you have an idea please tell me. :)

Wish I had ;). Actually I don't think there should be a specific
inheritance hierarchy (I don't really see what benefits it would do for
developers familiar with sockets). On level 0 just the class socket that
mimicks berkely sockets quite closely but only adds raii and unified
error reporting and exception based. (Or as in giallo

     /// Facade for the socket api
     class socket
         const address_family& address_family,
         const socket_type& type,
         const protocol& protocol);

       io_result bind(address& addr);
       io_result listen(size_t backlog);
       io_result accept(socket& client, address& add);

       io_result connect(address& add);

       io_result recv(void* data, size_t len, int flags=0);
       io_result send(const void* data, size_t len, int flags=0);

       static io_result gethostbyname(
         const std::string& host,
         std::string& h_name,
         std::vector<std::string>& h_aliases, // alternate names
         std::vector<address>& h_addr_list // known addresses


You get the idea.

> However I took over your ideas about ACE and updated the package diagram at
> If we forget about the two
> yellow packages for a moment:
> * The red package belongs to level 0. I changed the name and now call it
> berkeley to emphasize that this package contains a C++ API of what is known
> to many programmers as Berkeley sockets. The idea of this package is that
> network developers who glance at the C++ network library recognize many
> concepts and switch over. They should look at the documentation, see a class
> socket and think: "I know everything about sockets - I can use these classes
> immediately."
> * The blue packages belong to level 1. I introduced a new package called ace
> because of the acceptor-connector pattern which is used in ACE. This package
> is for network programmers who look at the documentation, see
> application-level concepts and think: "I can connect my application to the
> network without understanding sockets."
> The package names were made up on the spot - there are probably better ones.
> The design however comes close to what we had already in the Wiki (see
> There are two levels described - one as a wrapper for the C API (the
> berkeley package), the other one for connector, acceptor and data connection
> (our ace package). BoostSocket/Streams is the iostream package in the
> diagram. The multiplexing library I once proposed myself is one of the four
> supported I/O models which can be used in level 0 (there must be something
> similar to select()) and in level 1 (if we follow ACE there will be
> something like the Reactor class).

This is as you state the same approach as outined in the BoostSocket
writings and Hugo Duncan implemented in giallo

I also think there is another fundamental question, should we go the
route proposed in giallo which is template based or a more
ineritance/interface based approach?

As we have to do with network io virtual dispatch wouldn't be a problem?


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