[chord] Chord queries relating to Initialisation and Join

[Aisling O' Driscoll]

Hi Emil,



Thanks for your replies os far and apologies for coming back to you again
but I am still a bit unclear between what is default Chord behaviour
according to their published SIGCOMM paper and what is specific to the MIT
Chord implementation.



   1. Question relating to MIT Chord Implementation: When you say that
   successor, predecessors and fingers are calculated dynamically based on a
   current set of known live nodes are you saying some type of global table is
   available to every node making them aware of what nodes are in the system
   i.e. this will ensure the ring is always consistent?



   1. Question relating to default SIGCOMM Chord behaviour (for construction
   of the ring). I describe a scenario below.



   - Node n wishes to join a Chord ring. There are no other nodes in the
   ring.
   - It sets its successor = n and its predecessor = NIL. It builds its
   finger table so that all finger successor entries are set to itself.
   - Subsequently node m wishes to join the network. Node m queries node n
   for its successor.
   - Node n replies that m’s successor is itself, n.
   - Node m sets its successor = n and its predecessor = NIL.
   - As per the Chord node joining procedure, node m then triggers the
   notify function informing node n of its existence so that it can update its
   predecessor pointer to m. At this point, Ns = n, Np = m, Ms = n, Mp = NIL.
   - Now this is where I am confused: Ordinarily, in a fully formed Chord
   ring, node n would at some point send a periodic stabilize function to its
   successor querying its predecessor. In this way it would learn about a new
   node that has joined in between node n and its successor, update it
   successor and notify the new node to update its predecessor pointer. Clearly
   node n’s successor should now be node m and node m’s predecessor should be
   node n. But node N is not going to send a stabilize packet to itself so I
   don’t know how the pointers will be correctly updated.
   - I also don’t understand how node m’s finger tables will be correctly
   constructed. Node m will construct its finger table by making node n do a
   lookup for each entry. But this will always return node n (as that is all
   that’s currently located in node n’s finger table) so node m will never be
   referenced either node’s finger table (which is incorrect).



Many thanks in advance.


On Mon, May 24, 2010 at 7:29 PM, Emil Sit <sit at mit.edu> wrote:

> On Thu, May 20, 2010 at 5:55 PM, Aisling O' Driscoll
> <odriscoll.aisling at gmail.com> wrote:
> > 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?
>
> In the MIT Chord implementation, successors, predecessors and fingers
> are all calculated dynamically based on the current set of known live
> nodes.
>
> > 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
>
> That looks like someone's final paper for a class; I would stick with
> papers that appear on the main Chord web site as primary references.
>
> --
> Emil Sit / http://www.emilsit.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://amsterdam.lcs.mit.edu/pipermail/chord/attachments/20100525/c9f97479/attachment.htm