mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-28 12:37:55 +00:00
Code Issues Releases Wiki Activity

[2269] Developer's guide updated.

Browse Source
This commit is contained in:
Tomek Mrugalski 2012-10-01 19:19:49 +02:00
parent 43636d3f31
commit 5b9ab4bc5c
2 changed files with 62 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
doc/devel/mainpage.dox
View File

@ -15,12 +15,17 @@
* <a href="http://bind10.isc.org/">BIND10 webpage (http://bind10.isc.org)</a>
*
* @section DNS
* - Authoritative DNS (todo)
* - Recursive resolver (todo)
* - @subpage DataScrubbing
*
* @section DHCP
* - @subpage dhcpv4
* - @subpage dhcpv4Session
* - @subpage dhcpv6
* - @subpage dhcpv6-session
* - @subpage dhcpv6-config-parser
* - @subpage dhcpv6-config-inherit
* - @subpage libdhcp
* - @subpage libdhcpIntro
* - @subpage libdhcpIfaceMgr

115
src/bin/dhcp6/dhcp6.dox
View File

@ -1,71 +1,72 @@
/**
* @page dhcpv6 DHCPv6 Server Component
*
* BIND10 offers DHCPv6 server implementation. It is implemented as
* b10-dhcp6 component. Its primary code is located in
* isc::dhcp::Dhcpv6Srv class. It uses \ref libdhcp extensively,
* especially lib::dhcp::Pkt6, isc::dhcp::Option and
* isc::dhcp::IfaceMgr classes. Currently this code offers skeleton
* functionality, i.e. it is able to receive and process incoming
* requests and trasmit responses. However, it does not have database
* management, so it returns only one, hardcoded lease to whoever asks
* for it.
*
* DHCPv6 server component does not support relayed traffic yet, as
* support for relay decapsulation is not implemented yet.
*
* DHCPv6 server component does not use BIND10 logging yet.
*
* @section dhcpv6Session BIND10 message queue integration
*
* DHCPv4 server component is now integrated with BIND10 message queue.
* It follows the same principle as DHCPv4. See \ref dhcpv4Session for
* details.
@page dhcpv6 DHCPv6 Server Component
BIND10 offers DHCPv6 server implementation. It is implemented as
b10-dhcp6 component. Its primary code is located in
isc::dhcp::Dhcpv6Srv class. It uses \ref libdhcp extensively,
especially lib::dhcp::Pkt6, isc::dhcp::Option and
isc::dhcp::IfaceMgr classes. Currently this code offers skeleton
functionality, i.e. it is able to receive and process incoming
requests and trasmit responses. However, it does not have database
management, so it returns only one, hardcoded lease to whoever asks
for it.
DHCPv6 server component does not support relayed traffic yet, as
support for relay decapsulation is not implemented yet.
DHCPv6 server component does not use BIND10 logging yet.
@section dhcpv6-session BIND10 message queue integration
DHCPv4 server component is now integrated with BIND10 message queue.
It follows the same principle as DHCPv4. See \ref dhcpv4Session for
details.
@section dhcpv6-config-parser Configuration Parser in DHCPv6
b10-dhcp6 component uses BIND10 cfgmgr for commands and configuration. During
initial configuration (See \ref ControlledDhcpv6Srv::establishSession()),
the configuration handler callback is installed
(see ControlledDhcpv6Srv::dhcp6ConfigHandler(). It is called every time there
is a new configuration. In particular, it is called every time during daemon
start process. It contains a ConstElementPtr to a new configuration. This
simple handler calls \ref isc::dhcp::configureDhcp6Server() method that
processes received configuration.
initial configuration (See \ref
isc::dhcp::ControlledDhcpv6Srv::establishSession()), the configuration handler
callback is installed (see isc::dhcp::ControlledDhcpv6Srv::dhcp6ConfigHandler().
It is called every time there is a new configuration. In particular, it is
called every time during daemon start process. It contains a
isc::data::ConstElementPtr to a new configuration. This simple handler calls
\ref isc::dhcp::configureDhcp6Server() method that processes received configuration.
This method iterates over list of received configuration elements and creates
a list of parsers for each received entry. Parser is an object that is derived
from a \ref Dhcp6ConfigParser class. Once a parser is created (constructor),
its value is set (using build() method). Once all parsers are build, the
configuration is then applied ("commited") and commit() method is called.
This method iterates over list of received configuration elements and creates a
list of parsers for each received entry. Parser is an object that is derived
from a \ref isc::dhcp::Dhcp6ConfigParser class. Once a parser is created
(constructor), its value is set (using build() method). Once all parsers are
build, the configuration is then applied ("commited") and commit() method is
called.
All parsers are defined in src/bin/dhcp6/config_parser.cc file. Some
of them are generic (e.g. \ref Uint32Parser that is able to handle
any unsigned 32 bit integer), but some are very specialized
(e.g. \ref Subnets6ListConfigParser parses definitions of Subnet6 lists). In
All parsers are defined in src/bin/dhcp6/config_parser.cc file. Some of them
are generic (e.g. \ref isc::dhcp::Uint32Parser that is able to handle any
unsigned 32 bit integer), but some are very specialized (e.g. \ref
isc::dhcp::Subnets6ListConfigParser parses definitions of Subnet6 lists). In
some cases, e.g. subnet6 definitions, the configuration entry is not a simple
value, but a map or a list itself. In such case, the parser iterates over
all elements and creates parsers for a given scope. This process may be
repeated (sort of) recursively.
value, but a map or a list itself. In such case, the parser iterates over all
elements and creates parsers for a given scope. This process may be repeated
(sort of) recursively.
@section dhcpv6-config-inherit DHCPv6 Configuration Inheritance
One notable useful features of DHCP configuration is its parameter inheritance.
For example, renew-timer value may be specified at a global scope and it
then applies to all subnets. However, some subnets may have it overwritten
with more specific values that takes precedence over global values that are
considered defaults. Some parsers (e.g. \ref Uint32ConfigParser and
\StringParser) implement that inheritance. By default, they store values in
global uint32_defaults and string_defaults storages. However, it is possible
to instruct them to store parsed values in more specific storages. That
capability is used, e.g. in \ref Subnet6ConfigParser that has its own storage
that is unique for each subnet. Finally, during commit phase (commit() method),
appropriate parsers can use apply parameter inheritance.
For example, renew-timer value may be specified at a global scope and it then
applies to all subnets. However, some subnets may have it overwritten with more
specific values that takes precedence over global values that are considered
defaults. Some parsers (e.g. \ref isc::dhcp::Uint32Parser and \ref
isc::dhcp::StringParser) implement that inheritance. By default, they store
values in global uint32_defaults and string_defaults storages. However, it is
possible to instruct them to store parsed values in more specific
storages. That capability is used, e.g. in \ref isc::dhcp::Subnet6ConfigParser
that has its own storage that is unique for each subnet. Finally, during commit
phase (commit() method), appropriate parsers can use apply parameter inheritance.
Debugging configuration parser may be confusing. Therefore there is a special
class called \ref DummyParser. It does not configure anything, but just accepts
any parameter of any type. If requested to commit configuration, it will print
out received parameter name and its value. This class is not currently used,
class called \ref isc::dhcp::DummyParser. It does not configure anything, but just
accepts any parameter of any type. If requested to commit configuration, it will
print out received parameter name and its value. This class is not currently used,
but it is convenient to have it every time a new parameter is added to DHCP
configuration. For that purpose it should be left in the code.
@ -76,5 +77,3 @@
do not implement any fancy inheritance logic.
*/