On 6/14/07, Jim McCoy <[EMAIL PROTECTED]> 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. Alen _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
