| 1 | When a file is uploaded, the encoded shares are sent to other peers. But to |
|---|
| 2 | which ones? Likewise, when we want to download a file, which peers should we |
|---|
| 3 | ask for shares? The "peer selection" algorithm is used to make these choices. |
|---|
| 4 | |
|---|
| 5 | During the first tahoe meeting, (actualy on the drive back home), we designed |
|---|
| 6 | the now-abandoned "tahoe1" algorithm, which involved a "cabal" for each file, |
|---|
| 7 | where the peers involved would check up on each other to make sure the data |
|---|
| 8 | was still available. The big limitation was the expense of tracking which |
|---|
| 9 | nodes were parts of which cabals. |
|---|
| 10 | |
|---|
| 11 | When we release 0.2.0, we used the "tahoe3" algorithm (see |
|---|
| 12 | peer-selection-tahoe3.txt), but in v0.6 (ticket #132) we switched back to |
|---|
| 13 | "tahoe2" (see peer-selection-tahoe2.txt, and the PEER SELECTION section |
|---|
| 14 | of docs/architecture.rst), which uses a permuted peerid list and packs the |
|---|
| 15 | shares into the first 10 or so members of this list. (It is named "tahoe2" |
|---|
| 16 | because it was designed before "tahoe3" was.) |
|---|
| 17 | |
|---|
| 18 | In the future, we might move to an algorithm known as "denver airport", which |
|---|
| 19 | uses Chord-like routing to minimize the number of active connections. |
|---|
| 20 | |
|---|
| 21 | Different peer selection algorithms result in different properties: |
|---|
| 22 | * how well do we handle nodes leaving or joining the mesh (differences in the |
|---|
| 23 | peer list)? |
|---|
| 24 | * how many connections do we need to keep open? |
|---|
| 25 | * how many nodes must we speak to when uploading a file? |
|---|
| 26 | * if a file is unrecoverable, how long will it take for us to discover this |
|---|
| 27 | fact? |
|---|
| 28 | * how expensive is a file-checking operation? |
|---|
| 29 | * how well can we accomodate changes to encoding parameters? |
|---|
