[chord] redundancy in Chord

[Emil Sit]

Hello,

On Thu, 17 May 2007 at 15:45 (-0400), Durga Prasad Pandey wrote:
> I was wondering if Chord is designed to be redundant in the sense  
> that if a node goes down, would the files at that node have been  
> replicated elsewhere, perhaps in a distributed way(most likely) so  

Chord itself is technically only a lookup/rendezvous protocol.
Replication and maintenance is left to the application.  

> Another way of asking the question would be: does Chord allow for  
> multiple instances of a particular file to exist on different nodes,  
> and if Chord itself enables that capability or expects the  
> applications to do it own their own.

Chord is agnostic to data entirely: it only maps 160-bit numbers to
IP addresses (essentially): the application can use Chord to help
it select locations for replicas.  The CFS paper (SOSP 2001)
discusses some possibilities, as does the more recent Carbonite
paper (NSDI 2006).  You can examine Glacier (NSDI 2005) for yet
another take.

That said, DHash is our generic storage layer, built on top of
Chord.  It provides both simple replication and erasure-coding on
top of Chord; there are also two maintenance protocols implemented
that monitor replication levels and execute repairs when those
levels fail "dangerously low".  You can get the MIT Chord/DHash
implementation from the Chord homepage.

Other implementations of Chord may or may not support for
replication and storage; some are mentioned in the FAQ but I have
not used any of them myself.  If you are interested in a
non-libasync/C++ implementation, some of the other developers have
been known to pipe up on this list from time to time.

-- 
Emil Sit / MIT CSAIL PDOS / http://pdos.csail.mit.edu/chord/