[boost] Re: async socket i/o [long]

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

Boris wrote:
> Michel André wrote:

> 
> Agreed. In the beginning acceptor and connector in 
> http://www.highscore.de/boost/net/basic.png 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 
http://cvs.sourceforge.net/viewcvs.py/giallo/giallo/boost/net/socket/socket.hpp?view=markup)

     /// Facade for the socket api
     class socket
     {
       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 
> http://www.highscore.de/boost/net/packages.png. 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 
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket): 
> 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 
(http://giallo.sourceforge.net/).

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?

/Michel