]> git.ipfire.org Git - thirdparty/kea.git/commitdiff
[4497] Udated doxygen about copying retrieved options in hooks.
authorMarcin Siodelski <marcin@isc.org>
Wed, 6 Jul 2016 14:06:36 +0000 (16:06 +0200)
committerMarcin Siodelski <marcin@isc.org>
Fri, 8 Jul 2016 05:50:19 +0000 (07:50 +0200)
src/bin/dhcp4/dhcp4_hooks.dox
src/bin/dhcp6/dhcp6_hooks.dox

index f82308bf404e1955a54d4df6cdb7fbd21a884531..be9ce1f6eba28e5ded32d2c02ef5dd9d7fa9a40a 100644 (file)
@@ -291,4 +291,52 @@ packet processing. Hook points that are not specific to packet processing
   expired leases will remain in the database and their recovery will
   be attempted during the next reclaim cycle.
 
+@section dhcpv4HooksOptionsAccess Accessing DHCPv4 Options within a Packet
+When the server constructs a response message to a client it includes
+DHCP options configured for this client in a response message. Apart
+from the dynamically created options, such as Client FQDN option, it
+typically includes many options specified in the server configuration
+and held within the configuration structures by @c CfgMgr. Option
+instances are created once, during server configuration, and the
+@c CfgMgr holds pointers to those instances until the next server
+reconfiguration.
+
+When the server includes an option in a response message it copies
+a pointer to the instance of this option, rather than entire option.
+This ensures the good performance of response message creation. However,
+it also implies that any modification to the option carried in the
+DHCP response will affect an instance of this option in the server
+configuration structures. This is obviously not desired as it would
+affect all subsequent DHCP transactions involving this option. The
+DHCP server code avoids modifying the options included in the messages
+so it is possible to ensure good performance without a risk of
+accidentally modifying server configuration. The situation is
+different with hooks libraries which purpose is, in many cases,
+to modify values of options inserted by the server.
+
+Thus, @c Pkt class provides a mechanism to return a copy of an
+option to a caller (e.g. a callout), rather than an instance
+shared with the @c CfgMgr. This mechanism is enabled for all instances
+of @c Pkt4 passed to the callouts, i.e. "query4" and "response4"
+arguments. It is also automatically disabled when the callout
+returns the control back to the server.
+
+At every hook point, where the server passes an instance of a packet
+to the callouts, the server calls
+@c isc::dhcp::Pkt4::setCopyRetrievedOptions (true)
+to force copying options retrieved by @c isc::dhcp::Pkt4::getOption
+within callouts. The copied option replaces an original option within a
+packet and any modification to the option content by the callout
+would only affect the option instance associated with the packet.
+
+On the other hand, copying each retrieved option may be expensive.
+If performance of a hook library is a concern, it is possible for the
+hook library to disable copying retrieved options by calling
+@c isc::dhcp::Pkt4::setCopyRetrievedOptions (false) within a callout.
+In this case however, the hook library implementer must be aware that any
+modification of the option instance would affect the server configuration
+and may disrupt server's operation. Thus, disabling copying of retrieved
+options is not recommended unless the hook library is not intended
+to modify configured options carried within a packet.
+
 */
index aa7cc9d2629573e3676342796756572c8c50f8fe..6fb87628fe775c1c4810a0b16b2b26be1b8e224b 100644 (file)
@@ -333,4 +333,55 @@ packet processing. Hook points that are not specific to packet processing
   expired leases will remain in the database and their recovery will
   be attempted during the next reclaim cycle.
 
+@section dhcpv6HooksOptionsAccess Accessing DHCPv6 Options within a Packet
+When the server constructs a response message to a client it includes
+DHCP options configured for this client in a response message. Apart
+from the dynamically created options, such as IA_NA or ClientFQDN, it
+typically includes many options specified in the server configuration
+and held within the configuration structures by @c CfgMgr. Option
+instances are created once, during server configuration, and the
+@c CfgMgr holds pointers to those instances until the next server
+reconfiguration.
+
+When the server includes an option in a response message it copies
+a pointer to the instance of this option, rather than entire option.
+This ensures the good performance of response message creation. However,
+it also implies that any modification to the option carried in the
+DHCP response will affect an instance of this option in the server
+configuration structures. This is obviously not desired as it would
+affect all subsequent DHCP transactions involving this option. The
+DHCP server code avoids modifying the options included in the messages
+so it is possible to ensure good performance without a risk of
+accidentally modifying server configuration. The situation is
+different with hooks libraries which purpose is, in many cases,
+to modify values of options inserted by the server.
+
+Thus, @c Pkt class provides a mechanism to return a copy of an
+option to a caller (e.g. a callout), rather than an instance
+shared with the @c CfgMgr. This mechanism is enabled for all instances
+of @c Pkt6 passed to the callouts, i.e. "query6" and "response6"
+arguments. It is also automatically disabled when the callout
+returns the control back to the server.
+
+At every hook point, where the server passes an instance of a packet
+to the callouts, the server calls
+@c isc::dhcp::Pkt6::setCopyRetrievedOptions (true)
+to force copying options retrieved by @c isc::dhcp::Pkt6::getOption,
+@c isc::dhcp::Pkt6::getOptions, @c isc::dhcp::Pkt6::getRelayOption
+and @c isc::dhcp::Pkt6::getAnyRelayOption within callouts. The copied
+option replaces an original option within the packet and any
+modification to the option content by the callout would only affect
+the option instance associated with the packet.
+
+On the other hand, copying each retrieved option may be expensive.
+If performance of a hook library is a concern, it is possible for the
+hook library to disable copying retrieved options by calling
+@c isc::dhcp::Pkt6::setCopyRetrievedOptions (false) within a callout.
+In this case however, the hook library implementer must be aware that
+any modification of the option instance would affect the server
+configuration and may disrupt server's operation. Thus, disabling
+copying of retrieved options is not recommended unless the hook
+library is not intended to modify configured options carried
+within a packet.
+
 */