(This page is awfully out of date, it was just imported from the old IIP Wiki backups, which were already out of date!)
The NetworkDb, accessed by other components by the NetworkDatabaseFacade, manages the distribution and lookup of RouterInfo (keyed by H(RouterIdentity)) and LeaseSet (keyed by H(Destination)) structures. (Note: this page is a little out of date - the BroadcastNetworkDb has been replaced with the KademliaNetworkDb as of i2p 0.2.3)
Locally, everything is stored in the netDb directory (overridden by the router.networkDatabase.dbDir config property). In that dir is a file for each entry:
Periodically that directory is synchronized with the network db implementation in memory (aka write out new ones, delete removed ones, load new ones). This should simplify distribution of RouterInfo structures ("hey, send me your routerInfo" or "hey, send me all your routerInfo" to get integrated into the network).
The file router.info in the base install dir is duplicated here (stored as routerInfo-(base 64 of H(RouterIdentity)).dat as well)
Requests to lookup data come in two varieties via the NetworkDatabaseFacade - lookupXYZLocally and lookupXYZ. The former just checks the local db and blocks, and the latter is provided a pair of Jobs to be fired off once the data is received or lookup fails.
Requests to store data never blocks.
Currently the network database is kludged via the BroadcastNetworkDatabase implementation - it publishes all data given to it to all known routers, and the SearchDBJob wildly does a broadcast search (searching SEARCH_BREADTH (5) peers at a time, adding newly received peers to the list of possible peers, and keeping track of who it has asked already. similar to kademlia search, except without the xor metric)
The SendDBStoreMessageJob attempts to send the DatabaseStoreMessage via an outbound tunnel (using SendTunnelMessageJob) or if no satisfactory tunnels exist, it sends it through the SendDBStoreMessageAsGarlicJob which selects a set of peers (by asking the PeerManagement subsystem) to garlic route through and builds a garlic including that message and an ack (DeliveryStatusMessage). It then takes the garlic and fires a SendGarlicJob off.
Currently the SendDBStoreMessageJob is forced to send via garlic, and the garlic is configured to go directly to the destination, using no intermediary hops.
The BroadastNetworkDatabase needs to get cut and the send jobs need to get revised. This is planned for the 0.3 release.
The PeerManagement subsystem is accessed via the PeerManagerFacade - requesting the H(routerIdentity) of peers by providing a PeerSelectionCriteria
Currently its incredibly kludged - not maintaining any statistics, testing any peers, or doing anything intelligent. It simply picks random peers atm.
Testing peers is currently implemented but disabled - the CheckPeerTestPoolJob verifies that a sufficient number of peer test messages are in the OutNetMessagePool, but currently shortcircuits instead of queueing up some TestPeerJob jobs.
This subsystem is probably the most complex part of I2P to implement efficiently, requiring long term tracking of peer performance and testing their operation and reliability.