X-Git-Url: http://g0dil.de/git?a=blobdiff_plain;f=Socket%2FMainpage.dox;h=643cee8408efabe30ca303e5e2ff2189d6bc4430;hb=3601c83f32cad85638739f891218f1e5d9fa0896;hp=2721d3696778685f2e6d12b66b802baf87efeabb;hpb=032707d24b1059febe83ce56b11fd79df106c6e2;p=senf.git diff --git a/Socket/Mainpage.dox b/Socket/Mainpage.dox index 2721d36..643cee8 100644 --- a/Socket/Mainpage.dox +++ b/Socket/Mainpage.dox @@ -4,12 +4,13 @@ abstraction of the BSD socket API. The abstraction is based on several concepts: - \li The basic visible interface is a handle object - (senf::FileHandle and it's derived classes) - \li The socket interface relies on a policy framework to configure - it's functionality + \li The basic visible interface is a \link handle_group handle + object \endlink + \li The socket interface relies on a \link policy_group policy + framework \endlink to configure it's functionality \li The rest of the socket API is accessible using a classic - inheritance hierarchy of protocol classes + inheritance hierarchy of \link protocol_group protocol classes + \endlink The handle/body architecture provides automatic reference counted management of socket instances, the policy framework provides @@ -19,136 +20,65 @@ dependent options. \see \ref usage \n - \ref extend \n + \ref handle_group \n + \ref policy_group \n + \ref protocol_group \n + \ref extend \n \ref implementation */ /** \page usage Using the Socket Library - \section socket_handle The socket handle - Whenever you use the socket library, what you will be dealing with are senf::FileHandle derived instances. The socket library relies on reference counting to automatically manage the underlying socket representation. This frees you of having to manage the socket lifetime explicitly. - - \section socket_hierarchy The FileHandle hierarchy - - \image html FhHierarchy.png - - The senf::FileHandle class is the base of a hierarchy of socket - handle classes (realized as templates). These classes provide an - interface to the complete socket API. While going down the - inheritance hierarchy, the interface will be more and more - complete. - - The most complete interface is provided by - senf::ProtocolClientSocketHandle and - senf::ProtocolServerSocketHandle. The template Arguments specifies - the Protocol class of the underlying socket type. These are the - \e only classes having public constructors and are therefore the - only classes, which may be created by the library user. You will - normally use these classes by naming a specific socket typedef - (e.g. senf::TCPv4ClientSocketHandle). - - However, to aid writing flexible and generic code, the socket - library provides the senf::ClientSocketHandle and - senf::ServerSocketHandle class templates. These templates - implement a family of closely related classes based on the - specification of the socket policy. This policy specification may - be \e incomplete (see below). Instances of - senf::ClientSocketHandle/senf::ServerSocketHandle can be assigned - and converted to different ClientSocketHandle/ServerSocketHandle - types as long as the policy specifications are compatible. - - \attention It is very important, to (almost) always pass the socket - handle by value. The socket handle is a very lightweight - class and designed to be used like an ordinary built-in type. This - is very important in combination with the policy interface. - \section policy_framework The policy framework - - \image html SocketPolicy.png - - The policy framework conceptually implements a list of parallel - inheritance hierarchies each covering a specific interface aspect - of the socket handle. The socket handle itself only provides - minimal functionality. All further functionality is relayed to a - policy class, or more precisely, to a group of policy classes, one - for each policy axis. The policy axis are - -
SocketHandle member | Policy member |
---|---|
senf::ClientSocketHandle::read | ReadPolicy::read (\ref senf::ReadPolicyBase) |
senf::ClientSocketHandle::readfrom | ReadPolicy::readfrom (\ref senf::ReadPolicyBase) |
senf::ClientSocketHandle::write | WritePolicy::write (\ref senf::WritePolicyBase) |
senf::ClientSocketHandle::writeto | WritePolicy::writeto (\ref senf::WritePolicyBase) |
senf::ClientSocketHandle::connect | AddressingPolicy::connect (\ref senf::AddressingPolicyBase) |
senf::ClientSocketHandle::bind | AddressingPolicy::bind (\ref senf::AddressingPolicyBase) |
senf::ClientSocketHandle::peer | AddressingPolicy::peer (\ref senf::AddressingPolicyBase) |
senf::ClientSocketHandle::local | AddressingPolicy::local (\ref senf::AddressingPolicyBase) |
senf::ClientSocketHandle::rcvbuf | BufferingPolicy::sndbuf (\ref senf::BufferingPolicyBase) |
senf::ClientSocketHandle::sndbuf | BufferingPolicy::rcvbuf (\ref senf::BufferingPolicyBase) |
senf::ServerSocketHandle::bind | AddressingPolicy::bind (\ref senf::AddressingPolicyBase) |
senf::ServerSocketHandle::listen | CommunicationPolicy::listen (\ref senf::CommunicationPolicyBase) |
senf::ServerSocketHandle::local | AddressingPolicy::local (\ref senf::AddressingPolicyBase) |
senf::ServerSocketHandle::accept | CommunicationPolicy::accept (\ref senf::CommunicationPolicyBase) |
senf::ServerSocketHandle::acceptfrom | CommunicationPolicy::accept (\ref senf::CommunicationPolicyBase) |