* autoincrement peer index
* enable test network methods only if we're a subordinate atlas peer,
and not the main test thread
* locking bugfixes
* remove redundant code
* more debug output
instead of Metropolis-Hastings Random Walk with Backtracking. This is
in light of reading the SIGCOMM 2012 paper by Lee, Xu, and Eun. Also,
update documentation to briefly explain the peer selection and
exploration rationale.
* use metropolis-hastings random walk with random backtracking (variant of MRWB)
to sample the peer graph in as unbiased a way as we can. The only major
difference between this and MRWB is that we don't maintain a peer stack;
we just select a random peer instead of backtracking.
* keep the peer table and the peer database in sync--the table is the
cache-coherent copy.
* keep only 65536 peers. Hash the peer address and a nonce to select a
slot, and ping an old peer before evicting it on collision (and keep the
old peer on collision if it responds)
* a peer can ask for all other peers.
* remove up to 10 peers that are unhealthy per walk; add up to 10 new
peers that we discover on remote peer queries.
* use socket-determined peer address, not RPC-given peer address
* various code cleanups.
* push zonefiles if we receive them, and know of another peer that needs
them (i.e. should happen frequently near the chain tip)
* when getting the peer list, queue the requester for pinging
* move unit tests to integration test framework
* Atlas nodes are a lot like BitTorrent nodes, where the blockchain
gets used to encode the sequence of zonefiles (chunks) a peer goes and
fetches.
* Atlas nodes discover each other from a set of seed nodes, and try
to construct a K-regular network graph using a random walk through
the peers neighbor relations.
* Atlas nodes propagate peer information to each other in a "K-rarest
known peers that are alive" fashion, to encourage even peer mixing.
* Atlas nodes maintain a bitwise big-endian "zonefile inventory vector"
where bit i is set if the ith NAME_UPDATE's associated zonefile has
been obtained.
* Atlas nodes exchange zonefile inventory vectors amongst their
neighbors in an effort to find missing zonefiles. They obtain zonefiles
in a rarest-first fashion--i.e. the first missing zonefile to fetch
should be the one known by the least amount of neighbors.
* Atlas nodes occasionally refresh inventory vectors with neighbors to
ensure that knowledge of a zonefile propagates through the network.
This is mostly untested code, save for what the unit tests at the end of
the file cover. TODO: integrate with CircleCI
