[flud-devel] [p2p-hackers] announcing Allmydata-Tahoe v0.3

Alen Peacock alenlpeacock at gmail.com
Thu Jun 14 20:48:33 PDT 2007

On 6/14/07, Jim McCoy <mccoy at mad-scientist.com> wrote:
> [an excellent explanation of some other potential advantages
> of replication over erasure coding]

  The main problem I see with both the "make replicas of my file for
me, plzkthx" strategy and the "make some parity blocks and push them
out to other nodes for me, plzkthx" strategy are that they seem
inherently unfair when examined individually; a client node is
consuming more bandwidth and/or CPU on remote nodes than it is willing
to expend itself to get its own data stored.  There are probably ways
to enforce fairness here (by trading future CPU/bandwidth resources
for example), but that complicates things substantially, and more
importantly the *net* effect is no better than simply uploading the
extra parity bits myself.  If I only need to push 1x out for uploading
my own files but need to do Nx work for M other clients who are
simultaneously uploading their data to me, it doesn't seem like a win.

  I think I follow you when you say that with replication in this
example, you could theoretically finish the complete op in 3x time
instead of 4x, but I'm curious if such a [semi-]store-and-forward
system can really do that in practice, and if it would really be worth
the other problems you'd have to address (like how do I coerce those
other nodes to finish the last bit, how much work do I have to do to
detect/verify their operations, and how much work do I have to do when
one of them fails to complete, etc.)

  On the other hand, using these strategies in a centralized service
(that has lots of p2p-like nodes sitting in a datacenter[s]) *does*
make a lot of sense, and is quite clever.  It may even be useful in
some sort of a completely decentralized system where nodes can sell
resources for cash (notwithstanding that introducing money into the
mix makes things a bit hard) or have some other mechanism to make it
okay for some nodes to consume more than they contribute.  Definitely
some interesting ideas to think about.


More information about the flud-devel mailing list