The dhcpd-j's architecture is similar to common dynamic web server. It relies on a central database holding all persistent data, and one or more front-end servers (first tier server). This is a well proven architecture principle allowing for a wide range of scalability and high-availability solutions.

This architecture is a logical view. It can be used through a wide range of configuration, from a simple stand-alone LAN server to a ISP-wide DHCP for millions of customers.

[shema]

In this example, the dhcp-server is a all-in-one Java process holding all functions at once. It is very simple to install and works out-of-the-box. The front-end and database engine run in the same Java process.

The network topology is stored in a XML file, the dhcp-leases are stored via a HSQL database.

[shema]

Here, front-ends and back-end are on separate servers. Front-ends are deployed in server farms and load-balancing is done via separate network load balancers. More than one server farms can be deployed on separate sites, as long as they have a permanent connection to the database.

The database holds the network topology and the dhcp-leases. Database engine can be Oracle (work in progress) or MySQL (work in progress). It is highly recommended to build high-availability databases through clusters.

• Font-end servers should virtually no specific data. It should only have pure local information (ip/port to bind to) and configuration to connect to the back-end. All application configuration is loaded from the back-end. In fallback mode, when connection to db is not possible, the front-end uses the last configuration locally cached.
• Any change in network topology can be pushed to front-end servers without any server restart or service interruption. Only major configuration changes may require front-end restart.

• Network topology: this is the core of the server configuration. It contains all managed IP subnets and associated parameters. Network nodes are stored in a hierarchical tree. Each node in the tree holds its own configuration that overrides its parent node configuration on part or all parameters.
• Subnets, shared networks, address pools: eventually all address pools used to serve clients.
• Static addresses''': you can manually force IP addresses for specific clients
• Request filter: a logical predicate whether to handle the client request or not. This allows to silently ignored requests you don't want to handle (BOOTP, vendor class…)
• DHCP options: list of DHCP options sent back to the client. It can be static options or calculated options. At each node level, options can either replace or concatenate to parent node options.