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