#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
Note: See TracTickets for help on using tickets.