Opened at 2008-06-03T05:12:56Z
Last modified at 2010-02-11T03:35:09Z
#447 new enhancement
explore improved peer-selection approaches: chord, reliability-based
Reported by: | warner | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | undecided |
Component: | code-peerselection | Version: | 1.0.0 |
Keywords: | preservation scalability | Cc: | |
Launchpad Bug: |
Description
Our old roadmap.txt had "Upload Peer Selection step 3/4" listed as "reliability/goodness-point counting?" and "denver airport (chord)?" listed.
What this means: our current "tahoe two" design could be changed to take historical server reliability into account. A long time ago, we imagined a system in which each server would get a certain number of points (based upon their demonstrated reliability, either computed by the uploading client itself, through other peers, or by a centralized service). Peer selection would assign shares to peers until it had reached a certain number of points. The idea was to take advantage of relatively unreliable peers instead of just always sticking with the reliable ones.
The "dernver airport / chord" idea involved reducing the number of connections needed to work with several files from fully-connected mesh down to log(N) (see also #235). We wrote this down somewhere. The rough idea was to send messages out along the chords towards the region near the SI, bearing a request to hold shares. The nodes which received and accepted the request would then connect directly to the uploading node to receive the share data.
Change History (1)
comment:1 Changed at 2010-02-11T03:35:09Z by davidsarah
- Keywords preservation scalability added