Estimate how many of our tunnels the peer can join per hour.
History of NetDb related activities (lookups, replies, stores, etc)
Determine how well integrated the peer is - how likely they will be useful to us if we are trying to get further connected.
Order profiles by their capacity, but backwards (highest capacity / value first).
Manage the current state of the statistics Also maintain Sets for each of the capabilities in TRACKED_CAPS.
Base implementation that has simple algorithms and periodically saves state
Copied from http://www.i2p2.i2p/how_peerselection.html See also main() below for additional commentary by zzz.
Grab some peers that we want to test and probe them briefly to get some more accurate and up to date performance data.
Methods to update profiles.
Keep the peer profiles organized according to the tiered model.
Write profiles to disk at shutdown, read at startup.
Quantify how fast the peer is - how fast they respond to our requests, how fast they pass messages on, etc.
Order profiles by their speed (lowest first).
Tunnel related history information
Replaces integer subTierMode argument, for clarity
The peer manager logs information about the history and quality of network peers.
Peer capacity, speed and other parameters are calculated to determine in what cases we should use each peer.