[flud-devel] DHT justifications (was: DHT Performance? Design?)

Alen Peacock 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
efficiency.

  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.

Alen




More information about the flud-devel mailing list