1 / 18

Efficient File Lookup using Chord Protocol

This note discusses the problem of finding a file given its fileID and presents two approaches - a centralized index and a decentralized index using the Chord protocol. It covers the basics of Chord, including node mappings, storing files, operations like routing and joining, achieving robustness, and handling failures and leaving nodes.

virgilc
Download Presentation

Efficient File Lookup using Chord Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EECS 122: A Note on Project 3 Computer Science Division Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA 94720-1776

  2. Problem • Each node contains a set of files, and each file has associated a fileID • Find a file given itsfileID E F D E? C A B

  3. Two Approaches • Centralized index – 1st project • One node (server) maintains a IndexTable with entries of the form (fileID, node, fileName) • Given a fileID K, a client • Contacts the server • Gets back from server a set of entries of the form (K, nodei, fileNamei) • download fileNamei from nodei • Decentralized index – 3rd project (Stella) • IndexTable distributed across nodes • Big question: given a fileID K, find corresponding entries? • We use a simple variant of Chord protocol • Note: at high level, this is how eDonkey works!

  4. Chord: Big Picture • Assume circular identifier (ID) space is 0..2m-1 • To each node we associate a unique ID in this identifier space • Each node is responsible for all IDs between itself and its predecessor on this circle

  5. Assume m=6  ID space is 0..63 Node 8 is responsible for [5,8] Node 15 is responsible for [9,15] Node 20 is responsible for [16, 20] … Node 4 is responsible [59, 4] Example: Identifier to Node Mapping 4 58 8 15 44 20 35 32

  6. (60, node32, C) (5, node20, D) (3, node44, A) (33, node44, B) Stella Overview: Storing Files • Each file has associated a fileID. • fileID is mapped in the node ID space • An entry (fileID, node, fileName) is inserted at node responsible for fileID • node = (IPaddr, port) 4 58 8 15 44 20 3 A 5 33 B D 35 32 60 C

  7. Each node maintains its successor and predecessor E.g., succ(58) = 4; succ(8) = 15 pred(58) = 44; pred(8) = 4 Route packet (ID, data) to the node responsible for ID using successor pointers Basic Operation: Route to a Given ID route(34,data) 4 58 8 15 44 20 35 32

  8. Basic Chord Protocol • Each node A periodically • sends a stabilize() message to its successor B • Upon receiving a stabilize() message a node B • returns its predecessor B’ to A by sending a notify() message • Upon receiving notify() from B, • if B’ is between A and B, A updates its successor to B’; • otherwise A doesn’t do anything

  9. Joining Operation • Node with ID=50 joins the ring • Node 50 needs to know at least one node already in the system • Assume known node is node15 4 58 8 15 50 44 20 35 32

  10. notify(58) join(50) Joining Operation: notify() • Node 50 asks node 15 to forward join message • When join(50) reaches the destination (i.e., node 58), node 58 (1) updates its predecessor to 50, and (2) returns a notify message to node 50 • Node 50 updates its successor to 58 pred=50 4 58 8 succ=58 15 50 route(50, join, node50) 44 20 35 32

  11. notify(predecessor=50) stabilize() Joining Operation: stabilize()/notify() • Node 44 sends a stabilize message to its successor, node 58 • Node 58 reply with a notify message • Node 44 updates its successor to 50 pred=50 4 58 8 succ=58 15 50 44 20 succ=50 35 32

  12. Stabilize() Joining Operation (cont’d) • Node 44 sends a stabilize message to its new successor, node 50 • Node 50 sets its predecessor to node 44 pred=50 4 58 8 succ=58 pred=44 15 50 44 20 succ=50 35 32

  13. Joining Operation (cont’d) • This completes the joining operation! pred=50 4 58 8 succ=58 50 pred=44 15 44 20 succ=50 35 32

  14. Achieving Robustness • To improve robustness each node maintains the k (> 1) immediate successors instead of only one successor • In the notify() message, node A can send its k-1 successors to its predecessor B • Upon receiving notify() message, B can update its successor list by concatenating the successor list received from A with A itself

  15. stabilize() Failure and Leaving Operation • Failure and leaving are treated the same way! • Assume each node maintains two successors • Assume node 44 fails • Node 35: • if no notify() is received after three stabilize() messages remove successor • Node 50: • if three stabilize() messages are missing remove predecessor 4 58 8 pred = 44 50 15 44 20 35 32 succ=44 succ’=50

  16. Failure and Leaving Operation • Node 35: • new succ=50 • next stabilize() sent to 50 • Node 50: • update pred=35 4 58 8 pred = ? 50 15 stabilize() 44 20 35 32 succ=50 succ’= ?

  17. notify(pred=35,succ=58) Failure and Leaving Operation • Node 50: • send notify() to 35, including (pred=35,succ=58) • Node 35: • update succ’=58 4 58 8 pred = 35 50 15 44 20 35 32 succ=50 succ’= ?

  18. notify(pred=35,succ=58) Failure and Leaving Operation • Node 50: • send notify() to 35, including (pred=35,succ=58) • Node 35: • update succ’=58 4 58 8 pred = 35 50 15 44 20 35 32 succ=50 succ’= 58

More Related