[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

  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 mailing list