Browse Source

[3484] Updated sections of the Developer's Guide concerning libdhcp++.

Marcin Siodelski 9 years ago
parent
commit
96fac8d57e
1 changed files with 42 additions and 44 deletions
  1. 42 44
      src/lib/dhcp/libdhcp++.dox

+ 42 - 44
src/lib/dhcp/libdhcp++.dox

@@ -1,4 +1,4 @@
-// Copyright (C) 2012-2014  Internet Systems Consortium, Inc. ("ISC")
+// Copyright (C) 2012-2015  Internet Systems Consortium, Inc. ("ISC")
 //
 //
 // Permission to use, copy, modify, and/or distribute this software for any
 // Permission to use, copy, modify, and/or distribute this software for any
 // purpose with or without fee is hereby granted, provided that the above
 // purpose with or without fee is hereby granted, provided that the above
@@ -31,32 +31,45 @@ The following classes for packet manipulation are implemented:
 - isc::dhcp::Pkt4 - represents DHCPv4 packet.
 - isc::dhcp::Pkt4 - represents DHCPv4 packet.
 - isc::dhcp::Pkt6 - represents DHCPv6 packet.
 - isc::dhcp::Pkt6 - represents DHCPv6 packet.
 
 
-There are two pointer types defined: Pkt4Ptr and Pkt6Ptr. They are
-smart pointer and are using boost::shared_ptr. There are not const
-versions defined, as we assume that hooks can modify any aspect of
-the packet at almost any stage of processing.
+The following pointer types are defined: \c Pkt4Ptr and \c Pkt6Ptr. They are
+smart pointers using the \c boost::shared_ptr type. There are no const
+versions of packet types defined, as we assume that hooks can modify any
+aspect of the packet at almost any stage of processing.
 
 
-Both packets use collection of Option objects to represent DHCPv4
-and DHCPv6 options. The base class -- Option -- can be used to
+Both packet types use collection of \ref isc::dhcp::Option objects to
+represent DHCPv4 and DHCPv6 options. The base class @c Option can be used to
 represent generic option that contains collection of
 represent generic option that contains collection of
-bytes. Depending on if the option is instantiated as v4 or v6
+bytes. Depending on whether the option is instantiated as DHCPv4 or DHCPv6
 option, it will adjust its header (DHCPv4 options use 1 octet for
 option, it will adjust its header (DHCPv4 options use 1 octet for
 type and 1 octet for length, while DHCPv6 options use 2 bytes for
 type and 1 octet for length, while DHCPv6 options use 2 bytes for
 each).
 each).
 
 
-There are many specialized classes that are intended to handle options with
-specific content:
+There are many specialized classes that are intended to handle options having
+specific formats:
 - isc::dhcp::Option4AddrLst -- DHCPv4 option, contains one or more IPv4 addresses;
 - isc::dhcp::Option4AddrLst -- DHCPv4 option, contains one or more IPv4 addresses;
 - isc::dhcp::Option6AddrLst -- DHCPv6 option, contains one or more IPv6 addresses;
 - isc::dhcp::Option6AddrLst -- DHCPv6 option, contains one or more IPv6 addresses;
-- isc::dhcp::Option6IAAddr -- DHCPv6 option, represents IAADDR_OPTION (an option that
-                    contains IPv6 address with extra parameters);
+- isc::dhcp::Option4ClientFqdn -- DHCPv4 Client FQDN option;
+- isc::dhcp::Option6ClientFqdn -- DHCPv6 Client FQDN option;
+- isc::dhcp::Option6IAAddr -- DHCPv6 option, represents IAADDR option (an option that
+                              contains IPv6 address with extra parameters);
+- isc::dhcp::Option6IAPrefix -- DHCPv6 option, represents IAPREFIX option (an option
+                                that contains IPv6 prefix in prefix delegation);
 - isc::dhcp::Option6IA -- DHCPv6 option used to store IA_NA and its suboptions.
 - isc::dhcp::Option6IA -- DHCPv6 option used to store IA_NA and its suboptions.
-
-All options can store sub-options (i.e. options that are stored within option
-rather than in a message directly). This functionality is commonly used in
-DHCPv6, but is rarely used in DHCPv4. isc::dhcp::Option::addOption(),
-isc::dhcp::Option::delOption(), isc::dhcp::Option::getOption() can be used
-for that purpose.
+- isc::dhcp::Option6StatusCode -- DHCPv6 option, carries a status code to the client;
+- isc::dhcp::OptionCustom -- Represents option having many different formats, where
+                             data fields can be accessed in a convenient way;
+- isc::dhcp::OptionInt -- DHCPv4 or DHCPv6 option, carries a single numeric value;
+- isc::dhcp::OptionString -- DHCPv4 or DHCPv6 option, carries a text value;
+- isc::dhcp::OptionVendor -- DHCPv4 or DHCPv6 option, carries Vendor Specific
+                             Information;
+- isc::dhcp::OptionVendorClass -- DHCPv4 or DHCPv6 option, contains vendor class
+                                  information.
+
+Various options can store sub-options (i.e. options that are stored within an
+option rather than in a message directly). This functionality is commonly used in
+DHCPv6, but is rarely used in DHCPv4. \ref isc::dhcp::Option::addOption(),
+\ref isc::dhcp::Option::delOption(), \ref isc::dhcp::Option::getOption() can
+be used to add, remove and retrieve sub-options from within an option.
 
 
 @section libdhcpRelay Relay v6 support in Pkt6
 @section libdhcpRelay Relay v6 support in Pkt6
 
 
@@ -80,7 +93,7 @@ that interface-id in its copy, when sending data back to the client.
 This will be used by the relay to choose proper interface when forwarding
 This will be used by the relay to choose proper interface when forwarding
 response towards the client.
 response towards the client.
 
 
-Pkt6 class has a public Pkt6::relay_info_ field, which is of type Pkt6::RelayInfo.
+Pkt6 class has a public \c Pkt6::relay_info_ field, which is of type \c Pkt6::RelayInfo.
 This is a simple structure that represents the information in each RELAY_FORW
 This is a simple structure that represents the information in each RELAY_FORW
 or RELAY_REPL message. It is important to understand the order in which
 or RELAY_REPL message. It is important to understand the order in which
 the data appear here. Consider the following network:
 the data appear here. Consider the following network:
@@ -93,7 +106,7 @@ Client will transmit SOLICIT message. Relay1 will forward it as
 RELAY_FORW with SOLICIT in it. Relay2 forward it as RELAY_FORW with
 RELAY_FORW with SOLICIT in it. Relay2 forward it as RELAY_FORW with
 RELAY_FORW with SOLICIT in it. Finally the third relay will add yet
 RELAY_FORW with SOLICIT in it. Finally the third relay will add yet
 another RELAY_FORW around it. The server will parse the packet and
 another RELAY_FORW around it. The server will parse the packet and
-create Pkt6 object for it. Its relay_info_ will have 3
+create \c Pkt6 object for it. Its relay_info_ will have 3
 elements. Packet parsing is done in reverse order, compare to the
 elements. Packet parsing is done in reverse order, compare to the
 order the packet traversed in the network.  The first element
 order the packet traversed in the network.  The first element
 (relay_info_[0]) will represent relay3 information (the "last" relay or
 (relay_info_[0]) will represent relay3 information (the "last" relay or
@@ -103,40 +116,25 @@ the first relay (relay1) or in other words the one closest to the client.
 
 
 Packets sent by the server must maintain the same encapsulation order.
 Packets sent by the server must maintain the same encapsulation order.
 This is easy to do - just copy data from client's message object into
 This is easy to do - just copy data from client's message object into
-server's response object. See Pkt6::coyRelayInfo for details.
+server's response object. See @ref isc::dhcp::Pkt6::RelayInfo for details.
 
 
 @section libdhcpIfaceMgr Interface Manager
 @section libdhcpIfaceMgr Interface Manager
 
 
-Interface Manager (or IfaceMgr) is an abstraction layer about low-level
+Interface Manager (or IfaceMgr) is an abstraction layer for low-level
 network operations. In particlar, it provides information about existing
 network operations. In particlar, it provides information about existing
-network interfaces See isc::dhcp::IfaceMgr::Iface class and
-isc::dhcp::IfaceMgr::detectIfaces() and isc::dhcp::IfaceMgr::getIface().
-
-Currently there is interface detection is implemented in Linux and BSD.
-There are plans to implement such support for other OSes, but they
-remain low priority for now.
+network interfaces See @ref isc::dhcp::Iface class and
+@ref isc::dhcp::IfaceMgr::detectIfaces() and @ref isc::dhcp::IfaceMgr::getIface().
 
 
-Generic parts of the code are isc::dhcp::IfaceMgr class in
+Generic parts of the code are @ref isc::dhcp::IfaceMgr class in
 src/lib/dhcp/iface_mgr.cc file. OS-specific code is located in separate
 src/lib/dhcp/iface_mgr.cc file. OS-specific code is located in separate
 files, e.g. iface_mgr_linux.cc, iface_mgr_bsd. Such separation should be
 files, e.g. iface_mgr_linux.cc, iface_mgr_bsd. Such separation should be
 maintained when additional code will be developed.
 maintained when additional code will be developed.
 
 
-For systems that interface detection is not supported on, there is a stub
-mechanism implemented. It assumes that interface name is read from a text
-file. This is a temporary solution and will be removed as soon as proper
-interface detection is implemented. It is not going to be developed further.
-To use this feature, store interfaces.txt file. It uses a simple syntax.
-Each line represents an interface name, followed by IPv4 or IPv6 address
-that follows it. This is usually link-local IPv6 address that the server
-should bind to. In theory this mechanism also supports IPv4, but it was
-never tested. The code currently supports only a single interface defined
-that way.
-
 Other useful methods are dedicated to transmission
 Other useful methods are dedicated to transmission
-(isc::dhcp::IfaceMgr::send(), 2 overloads) and reception
-(isc::dhcp::IfaceMgr::receive4() and isc::dhcp::IfaceMgr::receive6()).
-Note that receive4() and receive6() methods may return NULL, e.g.
-when timeout is reached or if dhcp daemon receives a signal.
+(\ref isc::dhcp::IfaceMgr::send(), 2 overloads) and reception
+(\ref isc::dhcp::IfaceMgr::receive4() and \ref isc::dhcp::IfaceMgr::receive6()).
+Note that \c receive4() and \c receive6() methods may return NULL, e.g.
+when timeout is reached or if the DHCP daemon receives a signal.
 
 
 @section libdhcpPktFilter Switchable Packet Filter objects used by Interface Manager
 @section libdhcpPktFilter Switchable Packet Filter objects used by Interface Manager