From 1338318644eb162f54b70f4088937e9beec1ae99 Mon Sep 17 00:00:00 2001 From: kevan Date: Thu, 13 May 2010 17:38:52 -0700 Subject: [PATCH] Update 'docs/architecture.txt' to reflect readonly share discovery --- docs/architecture.txt | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/docs/architecture.txt b/docs/architecture.txt index b1a53a8d..3d4d90c0 100644 --- a/docs/architecture.txt +++ b/docs/architecture.txt @@ -146,14 +146,20 @@ In the current version, the storage index is used to consistently-permute the set of all peer nodes (by sorting the peer nodes by HASH(storage_index+peerid)). Each file gets a different permutation, which (on average) will evenly distribute shares among the grid and avoid hotspots. - -We use this permuted list of nodes to ask each node, in turn, if it will hold -a share for us, by sending an 'allocate_buckets() query' to each one. Some -will say yes, others (those who are full) will say no: when a node refuses -our request, we just take that share to the next node on the list. We keep -going until we run out of shares to place. At the end of the process, we'll -have a table that maps each share number to a node, and then we can begin the -encode+push phase, using the table to decide where each share should be sent. +We first remove any peer nodes that cannot hold an encoded share for our file, +and then ask some of the peers that we have removed if they are already +holding encoded shares for our file; we use this information later. This step +helps conserve space, time, and bandwidth by making the upload process less +likely to upload encoded shares that already exist. + +We then use this permuted list of nodes to ask each node, in turn, if it will +hold a share for us, by sending an 'allocate_buckets() query' to each one. +Some will say yes, others (those who have become full since the start of peer +selection) will say no: when a node refuses our request, we just take that +share to the next node on the list. We keep going until we run out of shares +to place. At the end of the process, we'll have a table that maps each share +number to a node, and then we can begin the encode+push phase, using the table +to decide where each share should be sent. Most of the time, this will result in one share per node, which gives us maximum reliability (since it disperses the failures as widely as possible). -- 2.45.2