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