There are two layers, on which the socket library can be extended: On the protocol layer and on the policy layer. Extending the protocol layer is quite simple and works as long as the desired protocol does use the same BSD API used by the standard internet protocols as implemented in the standard policies (i.e. it uses ordinary read() and write() or rcvfrom() or sendto() calls and so on).
If however the implementation of a policy feature needs to be changed, a new policy class has to be written. This also is not very complicated however the integration is more complex.
Most protocols can be implemented by just implementing a new protocol class. The protocol class must be derived from ConcreteSocketProtocol and takes the socket policy (as created by MakeSocketPolicy) as a template argument. See the documentation of this class for the interface. \attention You may want to use multiple inheritance as it is used in the implementation of the standard protocols (See \ref protocol_group). You must however be extra careful to ensure, that every class ultimately has SocketPolicy as a public \e virtual base. After the protocol class has been defined, you will probably want to provide typedefs for the new protocol sockets. If the new protocol is connection oriented, this will be like
If you have to extend the policy framework, you will need to be aware of some important
limitations of the socket library:
\li When you define a new policy for some axis, this new policy <em>must not</em> be derived
from one of the existing concrete policy classes (except of course the respective policy
axis base class). This is important since the policy type is \e not polymorphic. The policy
to be used is selected by the compiler using the \e static type, which is exactly what is
desired, since this allows calls to be efficiently inlined.
\li Therefore, extending the policy framework will make the new socket probably \e incompatible
with generic code which relies on the policy axis which is extended. Example: If you write a
new write policy because your protocol does not use ordinary write() system calls but some
protocol specific API, Then any generic function relying on WritablePolicy will \e not work
with the new socket, since the socket does \e not have this policy, it has some other kind
of write policy.
Therefore you need to be careful of what you are doing. The first step is to find out, which
policy you will have to implement. For this, find the ClientSocketHandle and/or
ServerSocketHandle members you want to change (see \ref ClientSocketHandle and \ref
ServerSocketHandle). Not all policy axis directly contribute to the SocketHandle
interface. However, some policy members additionally depend on other policy axis (example:
AddressingPolicy::connect is only defined if the communication policy is
ConnectedCommunication).
\see policy_group