warner at lothar.com
Mon Aug 10 21:44:58 UTC 2009
Shawn Willden wrote:
> Why would peer selection pick up a different set of servers? As I understand
> it, peer selection computes HASH(SID+peerid) for each peer, sorts the list
> and then starts at the top. It seems like it should produce the same peer
> set each time -- which is generally a good thing.
Because the peer-selection code only pays attention to servers which
respond "sure! I can hold your share!" when asked. It returns a subset
of the list provided by the Introducer. Actually the sequence of events is:
1: Introducer tells you about a set of servers "A"
2: client is able to connect to some smaller subset "B"
3: connected subset "B" is permuted according to storageindex
4: peer-selection asks permuted subset "B" in order, gets responses,
finds homes for shares, returns active subset "C"
5: upload code removes servers from active subset if they disconnect
or fail during upload, process finishes with subset "D"
If a server disconnects during upload, it will also be removed (via
RemoteReference.notifyOnDisconnect) from "B". So the next time
peer-selection is run, it will start with a smaller B than it had the
previous time. Any servers which were removed during upload (i.e. C-D)
will also be removed from B. If you only ever lose, say, one server per
day, then your second upload should not see any disconnects, because the
only server scheduled to bounce that day was already removed from B.
More information about the tahoe-dev