On Wed, 22 Apr 2009 10:34:09 -0600 Shawn Willden <[email protected]> wrote:
> What about using the permuted list to find a set of servers that know > the set of servers that hold the shares? The share location list > deployed to the first n servers in the permuted server list would be > small, so it wouldn't impose a large burden either on servers storing > the list or on clients uploading the list, and it would allow > complete freedom to place shares wherever the client wants them. Interesting. I had been thinking about putting a "other-share server hint list" on each share-holding server, as a bit of metadata next to the share. Repairers/rebalancers would be obligated to update it, and the server itself could verify the contents every once in a while (and also use the other shares to verify its own). But putting merely the share-server list on the permuted-list servers (wow, try saying that 10 times fast) might have some better properties. Or combine the two approaches. You'd only need to get one of the first-order servers to find the probable location of all of the second-order servers, and finding any of the second-order servers would give you a strong possibility of finding the rest of the second-order servers. If the server-selection algorithm is trying to keep all your download traffic local (whether at your mom's house or in a single colo), it could pick the most convenient/closest first-order server to get the list from, then choose whichever of the second-order servers met the requirements. interesting... -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
