links, typos
[Imported from Trac: page ServerSelection, version 3]
parent
feae9b1fb1
commit
5b0217e094
|
@ -20,11 +20,11 @@ would be pretty easy to make the uploader use different classes according to
|
|||
a `tahoe.cfg` option.
|
||||
|
||||
However, there are some additional properties that need to be satified by the
|
||||
sever-selection algorithm for it to work at all. The basic Tahoe model is
|
||||
server-selection algorithm for it to work at all. The basic Tahoe model is
|
||||
that the filecap is both necessary and sufficient (given some sort of grid
|
||||
membership) to recover the file. This means that the eventual
|
||||
**downloader** needs to be able to find the same servers, or at least have
|
||||
a sufficiently-high probability of finding "enough" servers within a
|
||||
a sufficiently high probability of finding "enough" servers within a
|
||||
reasonable amount of time, using only information which is found in the
|
||||
filecap.
|
||||
|
||||
|
@ -37,12 +37,12 @@ track down and update all of the old shares: the chance of accidental
|
|||
rollback increases when it cannot reliably/cheaply find them all.
|
||||
|
||||
Another potential goal is for the download process to be tolerant of new
|
||||
servers, removed servers, and shares which have been moved (possibly as the
|
||||
servers, removed servers, and shares that have been moved (possibly as the
|
||||
result of repair or "rebalancing"). Some use cases will care about this,
|
||||
while others may never change the set of active servers and won't care.
|
||||
|
||||
It's worth pointing out the properties we were trying to get when we came up
|
||||
with the current "tahoe2" algorithm:
|
||||
with the current "TahoeTwo" algorithm:
|
||||
|
||||
* for mostly static grids, download uses minimal do-you-have-share queries
|
||||
* adding one server should only increase download search time by 1/numservers
|
||||
|
@ -52,7 +52,7 @@ with the current "tahoe2" algorithm:
|
|||
* traffic load-balancing: all non-full servers get new shares at the same
|
||||
bytes-per-second, even if serverids are not uniformly distributed
|
||||
|
||||
We picked the pseudo-random permuted serverlist to get these properties. I'd
|
||||
love to be able to get stronger diversity among hosts, racks, or data
|
||||
centers, but I don't yet know how to get that **and** get the properties
|
||||
listed above, while keeping the filecaps small.
|
||||
We picked the pseudo-random permuted serverlist [on the [StorageIndex](StorageIndex)]dependent
|
||||
to get these properties. I'd love to be able to get stronger diversity among
|
||||
hosts, racks, or data centers, but I don't yet know how to get that **and**
|
||||
get the properties listed above, while keeping the filecaps small.
|
||||
|
|
Loading…
Reference in a new issue