X-Git-Url: http://g0dil.de/git?a=blobdiff_plain;f=Socket%2FSocketPolicy.hh;h=af32b65c15009f9a2e6738d410b505a9398f41a2;hb=bd9f9d3fd6fbcff0112a7bf48ab9284da9576b11;hp=5d48e6da070b1dc5cef02e16fa4e2e9bfdce51c8;hpb=49f2e00bdc4014b34361a0830e7ec365844ee67a;p=senf.git diff --git a/Socket/SocketPolicy.hh b/Socket/SocketPolicy.hh index 5d48e6d..af32b65 100644 --- a/Socket/SocketPolicy.hh +++ b/Socket/SocketPolicy.hh @@ -1,9 +1,9 @@ // $Id:SocketPolicy.hh 218 2007-03-20 14:39:32Z tho $ // // Copyright (C) 2006 -// Fraunhofer Institut fuer offene Kommunikationssysteme (FOKUS) -// Kompetenzzentrum fuer Satelitenkommunikation (SatCom) -// Stefan Bund +// Fraunhofer Institute for Open Communication Systems (FOKUS) +// Competence Center NETwork research (NET), St. Augustin, GERMANY +// Stefan Bund // // This program is free software; you can redistribute it and/or modify // it under the terms of the GNU General Public License as published by @@ -23,22 +23,25 @@ /** \file \brief Policy Framework public header - \todo We should probably remove BufferingPolicy from the interface, it does not make much sense - (how did I come to include it ??) - - \todo Do we want to support separate read and write policies. This allows to treat pipes within - this framework however, is this worth the effort? - - \idea Creating a new Socket will create 4 (!) new instances (The handle, the body, the policy - and the protocol) of which 3 (argh) (body, policy and protocol) live on the heap. This is - expensive. We should convert all the policy classes to singletons and assign the same - instance to all socket bodies with the same policy. This would reduce the number of heap - allocations per socket handle to two. + \idea Creating a new Socket will create 3 new instances (The handle, the body, the policy) of + which 2 (argh) (body, policy) live on the heap. This is expensive. We should convert all the + policy classes to singletons and assign the same instance to all socket bodies with the same + policy. This would reduce the number of heap allocations per socket handle to one (which is + already optimized using the pool_alloc_mixin) */ /** \defgroup policy_group The Policy Framework - \image html SocketPolicy.png +
+ \ref WritePolicyBase + \ref AddressingPolicyBase + \ref FramingPolicyBase + \ref PolicyBase + \ref SocketPolicy + \ref CommunicationPolicyBase + \ref ReadPolicyBase +
+ \htmlonly SocketPolicy \endhtmlonly \section policy_group_introduction Introduction to the Policy Framework @@ -58,10 +61,7 @@
readPolicy
configures the readability of the socket
-
writePolicy
configures the writability of the socket
- -
bufferingPolicy
configures, if and how buffering is configured for a - socket
+
writePolicy
configures the writability of the socket
The template senf::SocketPolicy combines these policy axis to form a concrete socket policy. In a concrete policy, each of these policy axis is assigned a value, the policy value. This value @@ -70,7 +70,7 @@ from the axis base class FramingPolicyBase. This base class also doubles as UnspecifiedFramingPolicy (which is just a typedef alias). If a policy axis is assigned this Unspecified type, the axis is left unspecified, the concrete policy will be incomplete. - + The senf::SocketPolicy template defines the behavior of a socket handle. The socket handle instances do not implement any socket functionality themselves instead deferring the implementation to the policy classes. The SocketHandle interface is therefore \e not implemented @@ -101,7 +101,7 @@ separately but at the same time for each policy axis: \code - // This defines an incomplete policy where addressingPolicy, writePolicy and bufferingPolicy + // This defines an incomplete policy where addressingPolicy and writePolicy // are unspecified typedef senf::MakeSocketPolicy< senf::StreamFramingPolicy, @@ -117,8 +117,7 @@ // StreamFramingPolicy, // ConnectedCommunicationPolicy, // ReadablePolicy, - // WritablePolicy, - // SocketBufferingPolicy>::policy + // WritablePolicy>::policy senf::TCPv4ClientSocketHandle tcpHandle (...); MyReadableHandle myHandle (tcpHandle); // Conversion to more basic socket handle @@ -130,10 +129,10 @@ meta-programming are needed. However, this information is only needed if you want to write new policy classes or want to use the policy framework explicitly for your own involved optimizations ... or if you are just plain curious :-) - + In the following discussion we will use the following conventions: \li \e Axis is one or \c AddressingPolicy, \c FramingPolicy, \c CommunicationPolicy, \c - ReadPolicy, \c WritePolicy or \c BufferingPolicy + ReadPolicy or \c WritePolicy \li \e socketPolicy is any socket policy (that is, an instantiation of the SocketPolicy template) \li \e trait is an any policy class (that is, any class derived from one of the axis base @@ -165,7 +164,7 @@ derives from SocketPolicyBase. This is simpler than checking the template directly).
\c template \c SocketPolicy < \e addressingPolicy, \e framingPolicy, \e communicationPolicy, - \e readPolicy, \e writePolicy, \e bufferingPolicy >
This is the central SocketPolicy + \e readPolicy, \e writePolicy >
This is the central SocketPolicy template. It combines a complete set of policy classes, one for each axis.
\c template \c MakeSocketPolicy < \e args >
\c MakeSocketPolicy is a template @@ -186,10 +185,10 @@ \section policy_implement Implementing Policy Classes - To define a new policy class, derive from the corresponding base class for your policy - axes. The only policy axis which might possibly need to be extended are the addressing policy - (AddressingPolicyBase) and the buffering policy (BufferingPolicyBase). See the Documentation of - these classes for more information on which members can be implemented. + To define a new policy class, derive from the corresponding base class for your policy axes. The + only policy axis which might possibly need to be extended is the addressing policy + (AddressingPolicyBase). See the Documentation of these classes for more information on which + members can be implemented. All members you define must be static. For any of the policy classes, you must only define those members which are supported by your implementation. If you leave out a member you automatically @@ -207,10 +206,10 @@ \code struct ExampleAddressingPolicy { - template - void connect(senf::SocketHandle handle, Address & addr, + template + void connect(senf::SocketHandle handle, Address & addr, typename senf::IfCommmunicationPolicyIs< - Policy, senf::ConnectedCommunicationPolicy>::type * = 0); + SPolicy, senf::ConnectedCommunicationPolicy>::type * = 0); }; \endcode @@ -238,13 +237,11 @@ as base classes to build other policy classes. */ -#ifndef HH_SocketPolicy_ -#define HH_SocketPolicy_ 1 +#ifndef HH_SENF_Socket_SocketPolicy_ +#define HH_SENF_Socket_SocketPolicy_ 1 // Custom includes -#include "GenericSockAddr.hh" - //#include "SocketPolicy.mpp" ///////////////////////////////hh.p//////////////////////////////////////// @@ -271,8 +268,7 @@ namespace senf { (FramingPolicy) \ (CommunicationPolicy) \ (ReadPolicy) \ - (WritePolicy) \ - (BufferingPolicy) + (WritePolicy) // Wer define these classes explicitly (and not with some macro // magic) because @@ -296,9 +292,9 @@ namespace senf { */ struct AddressingPolicyBase { - virtual ~AddressingPolicyBase() {} + virtual ~AddressingPolicyBase(); - typedef GenericSockAddr Address; + class Address { Address(); }; }; /** \brief Policy defining the framing format @@ -313,7 +309,7 @@ namespace senf { */ struct FramingPolicyBase { - virtual ~FramingPolicyBase() {} + virtual ~FramingPolicyBase(); }; /** \brief Policy defining, how peers are selected @@ -323,13 +319,12 @@ namespace senf { +
method void listen(FileHandle, unsigned backlog) Switch socket into listening state
method int accept(FileHandle, Address &) Accept a new connection
method int accept(FileHandle) Accept a new connection
The \c listen member is straight forward. The \c accept() member must return a new file descriptor (which will be used to create a new SocketHandle of the correct - type). Additionally, accept() should only be defined, if the Addressing policy is not \c - NoAddressingPolicy (which together with ConnectedCommunicationPolicy would identify a - point-to-point link with fixed communication partners). + type). \note This Policy only has two meaningful states: ConnectedCommunicationPolicy and UnconnectedCommunicationPolicy. It is probably not sensible to define a new @@ -339,7 +334,7 @@ namespace senf { */ struct CommunicationPolicyBase { - virtual ~CommunicationPolicyBase() {} + virtual ~CommunicationPolicyBase(); }; /** \brief Policy defining the readability @@ -352,7 +347,7 @@ namespace senf { The second member should only be enabled if the communication policy is - UnconnectedCommunication (otherwise it does not make sense since the communication partner + UnconnectedCommunicationPolicy (otherwise it does not make sense since the communication partner is fixed) (see AddressingPolicyBase on how to do this). \note This Policy only has two meaningful states: ReadablePolicy and NotReadablePolicy. It @@ -362,7 +357,7 @@ namespace senf { */ struct ReadPolicyBase { - virtual ~ReadPolicyBase() {} + virtual ~ReadPolicyBase(); }; /** \brief Policy defining the writability @@ -375,7 +370,7 @@ namespace senf { The second member should only be enabled if the communication policy is - UnconnectedCommunication (otherwise it does not make sense since the communication partner + UnconnectedCommunicationPolicy (otherwise it does not make sense since the communication partner is fixed) (see AddressingPolicyBase on how to do this). \note This Policy only has two meaningful states: WritablePolicy and NotWritablePolicy. It @@ -385,19 +380,7 @@ namespace senf { */ struct WritePolicyBase { - virtual ~WritePolicyBase() {} - }; - - /** \brief Policy defining the buffering interface - - The BufferingPolicy defines the buffer handling of the socket. It may provide the following - members: - - \see policy_group - */ - struct BufferingPolicyBase - { - virtual ~BufferingPolicyBase() {} + virtual ~WritePolicyBase(); }; // The implementation file will for each Policy declared above @@ -476,6 +459,8 @@ namespace senf { information. */ AddressingPolicyBase const & theAddressingPolicy() const = 0; + + virtual ~SocketPolicyBase(); }; /** \brief Collection of policy classes @@ -497,10 +482,15 @@ namespace senf { { /** \brief Check dynamic policy compatibility - This method will check the socket policy \a other against this policy. It will check, - whether \a other is a base policy (or the same) of this policy. This check is done - against the \e dynamic type of \a other using RTTI. It will throw \c std::bad_cast, if - the policy is not compatible. + This check will validate, that a socket with \a other as it's policy is convertible to a + socket with the current SocketPolicy as it's policy. This is true, if for each policy + axis, the policy class of that axis as defined in the \a other policy is convertible to + the policy class of that same axis in the current SocketPolicy instance (as is defined + by the template arguments). This again is true, if the \a other policy class is derived + from (or is the same as) the policy class taken from the current SocketPolicy instance. + + In other words, this call checks, that the current SocketPolicy (as defined via the + template arguments) is more generic than the \a other socket policy. \param[in] other SocketPolicy to check \throws std::bad_cast if \a other is not a compatible policy @@ -557,4 +547,6 @@ namespace senf { // c-file-style: "senf" // indent-tabs-mode: nil // ispell-local-dictionary: "american" +// compile-command: "scons -u test" +// comment-column: 40 // End: