[tahoe-dev] Resurrecting Mojo Nation

[Brian Warner]

On 6/9/12 9:07 PM, Jack Byer wrote:

> Are there any fundamental reason why a system like Mojo Nation
> couldn't work now that certain capabilities are available that weren't
> a decade ago?

Oh, one other thought: another challenge of Mojo Nation was that each
file involved hundreds or thousands of backend blocks, and the overhead
of finding/tracking/downloading all of them was pretty bad. If I
remember right, the blocks came in fixed sizes (powers of two, up to
maybe 1MB), and each included a little bit of data about all segments of
the file (to avoid the "chunking" reliability problem). The result was
high alacrity (you had to download the whole file before any part of it
became readable, so no streaming) and really bad disk IO patterns on
both upload and download.

The very first simplification we made in the Tahoe design process was to
use a small number (N=10) of variable-sized shares
(sharesize=filesize/k), and to locate those shares algorithmically (both
to decide where to put them, and to find them again during download).
That means fewer things to keep track of, and nobody trying to actually
keep track of them all the time.

In a more market-driven scheme, you need to be able to push shares to
cheap+reliable servers, find them again later, and also find the copies
that servers have bought from each other. Shares move around on you,
even when no clients are looking at them. That means more overhead:
instead of being able to determine offline (permuted ring) where shares
are likely to be, you have to actually ask everyone. To do this
efficiently requires log(N) DHT cleverness (where you don't actually ask
*everybody*), which allows some of them to lie (which they will, because
they don't want you to discover the competition's cheaper copies).

So the flexible share-placement required by a free storage market
probably comes at the cost of complexity and share-tracking overhead.

cheers,
 -Brian