[chord] dhashclient question

[Emil Sit]

On Wed, 01 February 2006 at 18:04 (-0700), Yanyan Wang wrote:
>From the explanation in your sigcomm paper, I expected about half of the 32 key
> retrievals should fail because of the key lost as the result of my killing one
> lsd process. But my result is all the retrievals succeed in getting the
> corresponding strings. I am very surprised at this result.

As noted in Section 3 of the SIGCOMM paper, the application using
Chord is responsible for things like replication.  In this case, you
are using a layer called DHash built on top of Chord and introduced
in the 2001 SOSP paper.  The simple answer to your question is that
DHash places redundant versions of your data on multiple nodes so even
if some nodes fail, the data will remain accessible.  We discuss some
more of our findings in our 2004 NSDI paper and also in our upcoming
2006 NSDI paper.   

> The logs of the live
> chord node for the retrieval of key 9f8ff2967cff70d7373cb304807e053a44d8a047
> are:
> 
> ...
> lsd: will order successors 1
> lsd: dhash_download failed: 9f8ff2967cff70d7373cb304807e053a44d8a047:0:1:
> DHASH_NOENT at 3eb6ccaf98300a77989e0059cbe9a465bbc6f35d

What happens is that the dhash part of the node you are talking to
obtains a list of potential candidates that may hold data relevant
to a given key and attempts to query each of them.  Of course, some
of them do not have the data (as shown by this message), but due
to the replication, some of them do. 

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