staticDHCPd 1.6.x planned

Once the 1.5.x expansions are done, 1.6.x will be built, featuring a semi-stateful view into address-assignment, through a simple table design: the IP/subnet/serial key assigned to a MAC will be grouped with an expiration timestamp, allowing for an unreliable view of which hosts currently have “leases” (hosts that simply asked for configuration data, without an IP, will be tracked, too, with a special typecode). For DHCPv4 clients, this will be largely informational, enabling only the addition of LEASEQUERY support, but when v2 is implemented for DHCPv6, it will allow for server-initiated RECONFIGURE events, as described in section 19 of RFC 3315, which are pretty important, given the nature of the networks staticDHCPd is intended to serve.

This new subsystem will be configurable, using options like enable_leasequery and enable_reconfigure; if not enabled, the corresponding tracking mechanisms will not be used, for performance reasons. The data will also be storable in a local SQLite database, instead of the standard storage (this also allows for a second database if using SQLite already, to allow for better thread concurrency), to avoid a second remote access hit, when speed really matters.

While on the subject of performance, non-crucial data, like the list of clients remaining to be reconfigured and temporarily blacklisted MACs, may be stored in an in-memory SQLite database, rather than Python data-structures: this should save memory at a slight cost of speed; tests and stats will be necessary to decide whether the trade-off is worthwhile, though.

Leave a Reply

Your email address will not be published. Required fields are marked *