[chord] Chord queries relating to Initialisation and Join

[Aisling O' Driscoll]

Hi Emil,



Thanks for your advice so far and clarify that correct routing relies on
successor pointers and only routing efficiency relies on finger tables. I
would just like to clarify one or two quick things on the points that you
made:



“In the location_table approach, as soon as node m notifies node n that it
is a predecessor, node n will be in the table and be automatically used as
some fingers.”



I have never heard of the “location_table” approach – Is this an approach
used in the one of the code implementations on this webpage?:
http://pdos.csail.mit.edu/chord/faq.html#lang





I don’t fully understand what you mean by “node n will in the table and be
automatically used as some fingers” – whose table?

Are you saying it works like this?: Node m will join, find out node n is its
successor and will run the stabilize function. Node n will reply to the
stabilize query saying its predecessor is nil. Because of that, node m will
send a notify message to n and n will update its predecessor to node m. Are
you saying this new predecessor should prompt node n to re-evaluate its
finger table entries to incorporate m and hence when node m subsequently
tries to build its finger table by querying lookups of node n’s finger
table, node m will also build a finger table that has a mix of node n and m
in the finger table entries? Thus if this is the case, every time a node
determines that it has a new successor or predecessor it dynamically updates
its finger tables?



“Well, I don't see how one could really have a new node proactively update
everyone else in a truly distributed and large scale system. So, yes, it may
take some time before everyone gets the fully updated finger tables doing
their own periodic fix_fingers.”


I had come across the attached paper that made use of an update_finger_table
function (pg 5). It made it sound like it was part of the default
specification so that’s what made me wonder if the finger tables were
proactively updated. I really just wanted to clarify the default behaviour.

Thanks for your help and clarifications.
Kind Regards,
Aisling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://amsterdam.lcs.mit.edu/pipermail/chord/attachments/20100520/36f8984b/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: comp247-p2p-survey.doc
Type: application/msword
Size: 228864 bytes
Desc: not available
Url : http://amsterdam.lcs.mit.edu/pipermail/chord/attachments/20100520/36f8984b/attachment-0001.doc