implement alternate allocators
Today we provide only the incremental allocator (last_allocated_address++). It is trivial but obviously leads to contention in a multi-thread allocation. I propose two other allocators:
-
hash based allocation (e.g. hash the client MAC address): it is stable (same client will likely get the same address) and predictable -
pure random: very secure, not stable nor predictable (with a real (vs fake) PRNG). Done in #969 (closed). -
FLQ: Free leases queue. Kea can create all leases on startup and keep going through this list. This uses more memory, but provide constant speed (or small speed up) when pool utilization grows. Implemented in #2780 (closed).
I am adding multi-threading label but it is only related.
Edited by Tomek Mrugalski