--- old/usr/src/cmd/cmd-inet/usr.lib/in.dhcpd/README.caching	2014-10-07 19:19:28.318442550 +0200
+++ /dev/null	2014-10-07 19:19:28.000000000 +0200
@@ -1,164 +0,0 @@
-#
-# CDDL HEADER START
-#
-# The contents of this file are subject to the terms of the
-# Common Development and Distribution License, Version 1.0 only
-# (the "License").  You may not use this file except in compliance
-# with the License.
-#
-# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-# or http://www.opensolaris.org/os/licensing.
-# See the License for the specific language governing permissions
-# and limitations under the License.
-#
-# When distributing Covered Code, include this CDDL HEADER in each
-# file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-# If applicable, add the following below this CDDL HEADER, with the
-# fields enclosed by brackets "[]" replaced with your own identifying
-# information: Portions Copyright [yyyy] [name of copyright owner]
-#
-# CDDL HEADER END
-#
-#
-# Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
-# Use is subject to license terms.
-# 
-
-The DHCP server cache implementation
-Zhenghui.Xie@sun.com
-
-
-#ident	"%Z%%M%	%I%	%E% SMI"
-
-INTRODUCTION
-============
-
-The Solaris DHCP server implements a caching mechanism to:
-
- 	* Ensure the ACK is consistent with the original OFFER, so that
-	  subsequent requests get the same answer.
-	* Ensure the same IP address isn't offered to a different client.
-	* Improve performance by reducing the frequency of datastore lookups.
-
-IMPLEMENTATION OVERVIEW
-=======================
-
-The cache implementation consists of a number of hash tables and lists,
-enumerated below, along with a timeout and refresh mechanism:
-
-	* A global DHCP table hash (ntable):
-
-	  Each active network table (dvsc_dnet_t) is hashed by subnet number
-	  into a global hash called 'ntable'.  The dsvc_dnet_t itself
-	  contains a variety of information about each subnet, an access
-	  handle to the underlying datastore, and a variety of caches which
-	  we describe next.
-
-	  An ntable hash entry will be removed after DHCP_NET_THRESHOLD
-	  seconds of inactivity.
-
-	* A per-network client hash (ctable):
-
-	  Each client structure (dsvc_clnt_t) is hashed by client identifier
-	  into the per-network ctable.  This table is used by the interface
-	  worker thread to get client information.
-
-	  A ctable hash entry will be removed if the client does not communicate
-	  with the server for DHCP_CLIENT_THRESHOLD seconds.
-
-	* A per-network offer hash (itable):
-
-	  The IP address associated with each pending OFFER is hashed into
-	  the per-network itable.  This table is used to reserve the offered
-	  and in-use IP addresses on the given network.
-
-	  An itable hash entry will be removed if more than DSVC_CV_OFFER_TTL
-	  seconds elapse without update_offer() being called on it.
-
-	* A per-network free record list (freerec):
-
-	  This is a cache of free records, populated with any unused records
-	  retrieved from previous datastore lookups or from IP addresses that
-	  have been explicitly released by DHCP clients.  This is the first
-	  list select_offer() consults.
-
-	  An entry in the freerec list expires after DSVC_CV_CACHE_TTL seconds.
-
-	* A per-network least recently used record list (lrurec)
-
-	  This is a cache of least recently used records, populated with any
-	  unused records retrieved from a previous datastore lookup for
-	  LRU records.  This is the second list select_offer() consults, after
-	  checking freerec.
-
-	  An entry in the lrurec list expires after DSVC_CV_CACHE_TTL seconds.
-
-The concurrency between the datastore and cached records is handled by the
-underlying datastore implementation using perimeters and is transparent to
-in.dhcpd.  $SRC/lib/libdhcpsvc/private/{private.c,public.c} implement the
-functions used by in.dhcpd and DHCP server admin tools to lookup and modify
-the underlying datastore records.
-
-TRANSACTIONS
-============
-
-When in.dhcpd receives a packet from a client, the interface thread first
-calls open_dnet() to retrieve the dsvc_dnet_t which describes the network.
-The dsvc_dnet_t is either in the ntable hash, in which case it is returned,
-or a new dsvc_dnet_t is allocated and inserted to ntable.  Then, using the
-dsvc_dnet_t, the interface thread calls open_clnt(), which searches the
-dsvc_dnet_t's ctable hash and returns the client structure (dsvc_clnt_t) if
-found.  Otherwise, a new dsvc_clnt_t is allocated and inserted into the
-ctable.  Finally, the packet is put to the client's packet list so that the
-client thread can process it.
-
-The client thread then processes the packet according to whether it's a
-DISCOVER, REQUEST, RELEASE, or DECLINE.
-
-For a DISCOVER:
-
-	1. If there is a pre-assigned IP for this client and the cached offer
-	   is not timed out, then use the IP and the record in the
-	   dsvc_clnt_t and make an OFFER.
-
-	2. If there is a pre-assigned IP but the cached offer is expired,
-	   remove the cached OFFER from the itable, and try to find a new
-	   record for the client (see below).
-
-	3. If there is no pre-assigned IP for this client, just try to find
-	   a new record for the client (see following text).
-
-	To find a new record, the client thread first searches the datastore
-	for a record matching the client identifier provided in the packet.
-	If none is found, then the free record list (freerec) and least
-	recently used record list (lrurec) are searched, in that order.  If
-	either freerec or lrurec is empty, or the head record on either list
-	is expired, in.dhcpd removes any existing records and attempts to
-	repopulate them by performing datastore lookups.  Finally, any
-	unused records are cached for later use.
-
-	If a usable record is found, the server generates and sends an OFFER
-	to the client.  Once sent, the client's dsvc_clnt_t is inserted to
-	the dsvc_dnet_t's itable if it is a new IP, or the itable is refreshed
-	if it is a pre-assigned IP.
-
-For a REQUEST:
-
-	1. If the REQUEST is a reply to a previous OFFER, it checks if the
-	   OFFER has expired.  If not, the itable timer is reset, the client
-	   record is updated, and the ACK is sent.  If it is expired and the
-	   address cannot be confirmed to still be free, the REQUEST is 
-	   silently ignored (and the client should eventually drop back
-	   to DISCOVER).
-
-	2. If the REQUEST is associated with a client INIT-REBOOT or a client
-	   extending a lease, then the client thread does a datastore lookup
-	   by client identifier.  If a match is found, the record is updated
-	   and an ACK is sent.
-
-If the packet is a RELEASE, the client thread modifies the record in the
-datastore so that it is marked free, and, if successful, puts the record onto
-the free record list (freerec).
-
-Finally, if the packet is a DECLINE, the client thread modifies the record in
-the datastore so that it is marked unusable.
