Design for the DHT (by Christian Grothoff):
===========================================

WARNING: The code has not been sufficiently tested yet and probably
has quite a few tricky bugs left in it.


The DHT code consists of 3 parts.  First, there is the DHT module, a
dynamically loaded plugin that provides DHT services to two different
sets of clients.  The DHT module provides the routing facilities and
registers two sets of handlers.  The first set of handlers are RPC
methods which are used to exchange DHT messages with other peers. The
code for this implementation (module/dht.c) also provides the DHT
service API to the rest of the GNUnet core.  The DHT service API is
defined in gnunet_dht_service.h.

On top of the DHT service API sits the DHT-CS API (module/cs.c).  It
provides DHT services to GNUnet clients.  In order to make access to
the CS-API more convenient, there exists the GNUnet-DHT client
library.  Its functions are defined in gnunet_dht_lib.h.  The library
code is defined in dht/tools together with a couple of demo-tools
(gnunet-dht-join and gnunet-dht-update).

Low-level details:
- periodically each peer checks if the buckets in the DHT are full;
  if there are fewer than ALPHA entries it tries to find additional
  peers which run DHT by broadcasting PINGs.
- each peer participates in 'table 0'.  Table 0 is a mapping of table IDs
  to peers participating in that table.
- each peer periodically performs a 'put' on 'table 0' for each table 
  that that peer is participating in
- get / put have two variants; if the peer has joined the table, the
  lookup goes though that chain; otherwise the peer first performs a 
  table-0 lookup to find an entry-point to the table;
- for each table that the peer has joined, it periodically attempts
  to find peers in its proximity that have also joined that table;
- routing tables are similar to kademlia (in terms of replacement 
  policy and ID space structure; the bucket size depends on the number
  of tables that the peer participates in)
