[flud-devel] DHT justifications (was: DHT Performance? Design?)
alenlpeacock at gmail.com
Sun Nov 11 08:14:57 PST 2007
On Nov 6, 2007 11:15 PM, Bill Broadley <bill at broadley.org> wrote:
> > In order to do verify ops, a node must possess a copy of the
> > data.
> Er, what? If I ask you to store a file, I prove I have it, you should
> store it for as long as we have an agreement. You can of course challenge
> any file I've stored for you. But you shouldn't continuously make me
> reprove I have the data. It is after all a backup service.
If the initiating node doesn't keep a copy of the data, how does it
do verify ops?
You could, of course, precompute a bunch of challange/response pairs
and then use those (we did this in ABS), but if you don't have a local
copy fo the data, at some point you run out of challenge/response
pairs have to download a copy of the data again. And if every node is
doing that, it results in extra overall system load and reduced
flud is a pure mirroring backup service, not a generic storage grid.
Rather than complicating things to support a non use case, flud just
requires that the initiator retain a copy of the data for as long as
it wants it to exist in the network. Once verification operations
cease, data can begin to decay.
More information about the flud-devel