Solaris DHCP Service Developer's Guide

Chapter 1 Overview of Solaris DHCP Data Access Architecture

This chapter presents an overview of the architecture of the Solaris Dynamic Host Configuration Protocol (DHCP) service introduced in the Solaris 8 7/01 operating environment. This overview can help you see where your work will fit into the architecture.

For general information about the Solaris DHCP service, see “About Solaris DHCP (Overview)” in System Administration Guide: IP Services.

The following topics are included:

Modular Framework

The Solaris DHCP service includes the DHCP daemon, administrative tools, and separate data access modules (called public modules) for different data storage facilities. Solaris DHCP provides an API that enables you to write your own public modules, implemented as shared objects, to support any data storage facility you want. When you integrate your public module into the Solaris DHCP framework, the DHCP service stores its data in your database using your public module. Public modules can be delivered independently of the Solaris DHCP service, enabling anyone to develop and deliver modules to support any data storage facility.

The first release of Solaris DHCP using this architecture provides public modules for ASCII files, NIS+, and file-system-based binary data stores. This manual provides information that enables developers to create their own public modules for any database.

DHCP Server Multithreading

The DHCP server implements multithreading, enabling it to service many clients simultaneously. Public modules are required to be MT-SAFE to support multithreading by the DHCP server, and this in itself allows the DHCP service to handle a larger number of clients. However, the capacity of the DHCP server is largely dependent on the capabilities of the data storage facility and the efficiency of the public module used to access the data. You can potentially increase the performance and capacity of your Solaris DHCP service by creating a public module for using a fast, high-capacity data storage facility.

Data Access Layers

The Solaris DHCP modular framework implementation employs the following data access layers:

The following figure shows the interaction of the architecture layers.

Figure 1–1 Architecture of Data Store Access in DHCP Service

Diagram with Application/Service Layer on top, Framework Configuration Layer in middle. Service Provider Layer on bottom connects to data store.

The Framework Configuration Layer

Functions implemented in are used by the Application/Service Layer to:

The /etc/inet/dhcpsvc.conf contains a number of configuration parameters for the DHCP service, including the following keywords relevant to the public module developer:


Public module to load. The value of RESOURCE matches the public module name. For example, the RESOURCE=SUNWfiles refers to public module Naming the Public Module and Data Store Containers explains the rules for naming public modules.


Location of DHCP containers within the data service that the public module exports. The value of PATH is specific to the data service. For example, a UNIX™ path name would be assigned to PATH for the SUNWfiles resource.


Configuration information specific to the public module. This is an optional keyword that you can use if the data service requires configuration information, such as authentication from the user. If you use this keyword, you must provide a public module management bean to prompt the user for information to set the keyword value. See Data Service Configuration and DHCP Management Tools. The module must also export the configure() function to receive the value of this keyword during module load time. See configure() for more information.

The Framework Configuration Layer also provides to the Service Provider Layer an optional API synchronization service, described in Synchronizing Access to File-System-Based Containers.

The Service Provider Layer API

The Service Provider Layer API consists of functions, data structures, and manifest constants contained in the /usr/include/dhcp_svc_public.h file.

The functions are summarized in the following table, with links to sections with more detail about each function.

Table 1–1 Service Provider Layer API Functions

API Function 


General functions for all data store containers 


Pass a configuration string to the data store. Optional function. 


Create the location in which the data store will reside. 


Return general status information for the data store. 


Return the version of the Service Provider Layer API implemented by the data store container. 

Functions for dhcptab containers


Return the dhcptab container name.


Open or create the dhcptab container.


Perform a query for records in the dhcptab container.


Add a record to the dhcptab container.


Modify an existing record in the dhcptab container.


Delete a record from the dhcptab container.


Close the dhcptab container.


Remove the dhcptab container from the data store.

Functions for DHCP network containers 


Return a list of DHCP network container names. 


Open or create a DHCP network container. 


Perform a query for records in a DHCP network container. 


Add a record to a DHCP network container. 


Modify an existing record in a DHCP network container. 


Delete a record from a DHCP network container. 


Close a DHCP network container. 


Remove a DHCP network container from the data store. 

Data Store Containers

The dhcptab and DHCP network tables are referred to generically as data store containers. By default, Solaris DHCP provides support for the container formats shown in the following table.

Data Service Supported 

Public Module 

File-system-based, ASCII format

NIS+ service

File-system-based, binary format