Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications <ul><ul><li>Ion Stoica Robert Morris </li></ul></u...
Introduction <ul><li>Efficient lookup of a node which stores data items for a particular search key. </li></ul><ul><li>Pro...
Problems addressed <ul><li>Load Balance: Distributed hash function spreads keys evenly over the nodes </li></ul><ul><li>De...
Chord Protocol <ul><li>Assumes communication in underlying network is both symmetric and transitive. </li></ul><ul><li>Ass...
Chord protocol <ul><li>Consistent hashing function assigns each node and key an m-bit identifier using SHA-1 base hash fun...
Chord protocol m = 6 10 nodes
Theorem <ul><li>For any set of N nodes and K keys, with  high probability : </li></ul><ul><ul><li>Each node is responsible...
Simple Key Location Scheme N1 N8 N14 N21 N32 N38 N42 N48 K45
Scalable Lookup Scheme N1 N8 N14 N21 N32 N38 N42 N48 N51 N56 Finger Table for N8 finger  1,2,3 finger  4 finger  6 finger ...
Scalable Lookup Scheme <ul><li>// ask node  n  to find the successor of  id </li></ul><ul><li>n.find_successor(id) </li></...
Lookup Using Finger Table N1 N8 N14 N21 N32 N38 N42 N51 N56 N48 lookup(54)
Scalable Lookup Scheme <ul><li>Each node forwards query at least halfway along distance remaining to the target </li></ul>...
Dynamic Operations and Failures <ul><li>Need to deal with: </li></ul><ul><ul><li>Node Joins and Stabilization </li></ul></...
Node Joins and Stabilization <ul><li>Node’s successor pointer should be up to date </li></ul><ul><ul><li>For correctly exe...
Node Joins and Stabilization <ul><li>C ontains 6 functions: </li></ul><ul><ul><li>create() </li></ul></ul><ul><ul><li>join...
Create() <ul><li>Creates a new Chord ring </li></ul><ul><li>n . create () </li></ul><ul><li>predecessor = nil; </li></ul><...
Join() <ul><li>Asks m to find the immediate successor   of n. </li></ul><ul><li>Doesn’t make rest of the network   aware o...
Stabilize() <ul><li>Called periodically to learn about new nodes </li></ul><ul><li>Asks n’s immediate successor about succ...
Notify() <ul><li>m thinks it might be n’s predecessor </li></ul><ul><li>n . notify (m) </li></ul><ul><li>if (predecessor i...
Fix_fingers() <ul><li>Periodically called to make sure that finger   table entries are correct </li></ul><ul><ul><li>New n...
Check_predecessor() <ul><li>Periodically called to check whether predecessor has failed </li></ul><ul><ul><li>If yes, it c...
Theorem 3 <ul><li>If any sequence of join operations is executed interleaved with stabilizations, then at some time after ...
Stabilization Protocol <ul><li>Guarantees to add nodes in a fashion to preserve reach ability </li></ul><ul><li>By itself ...
Impact of Node Joins on Lookups <ul><li>Correctness </li></ul><ul><ul><li>If finger table entries are reasonably current <...
Impact of Node Joins on Lookups <ul><li>Performance </li></ul><ul><ul><li>If stabilization is complete </li></ul></ul><ul>...
Theorem 4 <ul><li>If we take a stable network with N nodes with correct finger pointers, and another set of up to N nodes ...
Failure and Replication <ul><li>Correctness of the protocol relies on the fact of knowing correct successor </li></ul><ul>...
Theorem 5 <ul><li>If we use successor list of length r =  O(log N) in a network that is initially stable, and then every n...
Theorem 6 <ul><li>In a network that is initially stable, if every node fails with probability ½, then the expected time to...
Voluntary Node Departures <ul><li>Can be treated as node failures </li></ul><ul><li>Two possible enhancements </li></ul><u...
Conclusion <ul><li>Efficient location of the node that stores a desired data item is a fundamental problem in P2P networks...
Future Work <ul><li>Using Chord to detect and heal partitions whose nodes know of each other. </li></ul><ul><ul><li>Every ...
<ul><li>THANK YOU </li></ul>
Upcoming SlideShare
Loading in...5
×

A Scalable Peer To Peer Lookup Service For Internet Applications

626

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
626
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

A Scalable Peer To Peer Lookup Service For Internet Applications

  1. 1. Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications <ul><ul><li>Ion Stoica Robert Morris </li></ul></ul><ul><ul><li>David Liben-Nowell David R. Karger </li></ul></ul><ul><ul><li>M. Frans Kaashoek Frank Dabek </li></ul></ul><ul><ul><li>Hari Balakrishnan </li></ul></ul><ul><li>Presented By- </li></ul><ul><li>Manan Rawal, Bhaskar Gupta </li></ul>
  2. 2. Introduction <ul><li>Efficient lookup of a node which stores data items for a particular search key. </li></ul><ul><li>Provides only one operation: given a key, it maps the key onto a node. </li></ul><ul><li>Example applications: </li></ul><ul><ul><li>Co-operative Mirroring </li></ul></ul><ul><ul><li>Time-shared storage </li></ul></ul><ul><ul><li>Distributed indexes </li></ul></ul><ul><ul><li>Large-Scale combinatorial search </li></ul></ul>
  3. 3. Problems addressed <ul><li>Load Balance: Distributed hash function spreads keys evenly over the nodes </li></ul><ul><li>Decentralization: Fully distributed </li></ul><ul><li>Scalability: Lookup grows as a log of number of nodes </li></ul><ul><li>Availability: Automatically adjusts internal tables to reflect changes. </li></ul><ul><li>Flexible Naming: No constraints on key structure. </li></ul>
  4. 4. Chord Protocol <ul><li>Assumes communication in underlying network is both symmetric and transitive. </li></ul><ul><li>Assigns keys to nodes with consistent hashing </li></ul><ul><li>Hash function balances the load </li></ul><ul><li>When N th node joins or leaves only O(1/N) fraction of keys moved. </li></ul>
  5. 5. Chord protocol <ul><li>Consistent hashing function assigns each node and key an m-bit identifier using SHA-1 base hash function. </li></ul><ul><li>Node’s IP address is hashed. </li></ul><ul><li>Identifiers are ordered on a identifier circle modulo 2 m called a chord ring. </li></ul><ul><li>succesor(k) = first node whose identifier is >= identifier of k in identifier space. </li></ul>
  6. 6. Chord protocol m = 6 10 nodes
  7. 7. Theorem <ul><li>For any set of N nodes and K keys, with high probability : </li></ul><ul><ul><li>Each node is responsible for at most (1+e)K/N keys. </li></ul></ul><ul><ul><li>When an (N+1) st node joins or leaves the network, responsibility for O(K/N) keys changes hands. </li></ul></ul><ul><li>e = O(log N) </li></ul>
  8. 8. Simple Key Location Scheme N1 N8 N14 N21 N32 N38 N42 N48 K45
  9. 9. Scalable Lookup Scheme N1 N8 N14 N21 N32 N38 N42 N48 N51 N56 Finger Table for N8 finger 1,2,3 finger 4 finger 6 finger [k] = first node that succeeds (n+2 k-1 )mod2 m finger 5 N42 N8+32 N32 N8+16 N21 N8+8 N14 N8+4 N14 N8+2 N14 N8+1
  10. 10. Scalable Lookup Scheme <ul><li>// ask node n to find the successor of id </li></ul><ul><li>n.find_successor(id) </li></ul><ul><li>if (id belongs to (n, successor ]) </li></ul><ul><li>return successor ; </li></ul><ul><li>else </li></ul><ul><li>n0 = closest preceding node(id); </li></ul><ul><li>return n0. find_successor (id); </li></ul><ul><li>// search the local table for the highest predecessor of id </li></ul><ul><li>n.closest_preceding_node(id) </li></ul><ul><li>for i = m downto 1 </li></ul><ul><li>if ( finger [i] belongs to (n, id)) </li></ul><ul><li>return finger [i]; </li></ul><ul><li>return n; </li></ul>
  11. 11. Lookup Using Finger Table N1 N8 N14 N21 N32 N38 N42 N51 N56 N48 lookup(54)
  12. 12. Scalable Lookup Scheme <ul><li>Each node forwards query at least halfway along distance remaining to the target </li></ul><ul><li>Theorem: With high probability, the number of nodes that must be contacted to find a successor in a N-node network is O(log N) </li></ul>
  13. 13. Dynamic Operations and Failures <ul><li>Need to deal with: </li></ul><ul><ul><li>Node Joins and Stabilization </li></ul></ul><ul><ul><li>Impact of Node Joins on Lookups </li></ul></ul><ul><ul><li>Failure and Replication </li></ul></ul><ul><ul><li>Voluntary Node Departures </li></ul></ul>
  14. 14. Node Joins and Stabilization <ul><li>Node’s successor pointer should be up to date </li></ul><ul><ul><li>For correctly executing lookups </li></ul></ul><ul><li>Each node periodically runs a “Stabilization” Protocol </li></ul><ul><ul><li>Updates finger tables and successor pointers </li></ul></ul>
  15. 15. Node Joins and Stabilization <ul><li>C ontains 6 functions: </li></ul><ul><ul><li>create() </li></ul></ul><ul><ul><li>join() </li></ul></ul><ul><ul><li>stabilize() </li></ul></ul><ul><ul><li>notify() </li></ul></ul><ul><ul><li>fix_fingers() </li></ul></ul><ul><ul><li>check_predecessor() </li></ul></ul>
  16. 16. Create() <ul><li>Creates a new Chord ring </li></ul><ul><li>n . create () </li></ul><ul><li>predecessor = nil; </li></ul><ul><li>successor = n; </li></ul>
  17. 17. Join() <ul><li>Asks m to find the immediate successor of n. </li></ul><ul><li>Doesn’t make rest of the network aware of n. </li></ul><ul><li>n . join (m) </li></ul><ul><li>predecessor = nil; </li></ul><ul><li>successor = m . find_successor(n); </li></ul>
  18. 18. Stabilize() <ul><li>Called periodically to learn about new nodes </li></ul><ul><li>Asks n’s immediate successor about successor’s predecessor p </li></ul><ul><ul><li>Checks whether p should be n’s successor instead </li></ul></ul><ul><ul><li>Also notifies n’s successor about n’s existence, so that successor may change its predecessor to n, if necessary </li></ul></ul><ul><li>n . stabilize () </li></ul><ul><li>x = successor . predecessor; </li></ul><ul><li>if (x  (n , successor)) </li></ul><ul><li>successor = x; </li></ul><ul><li>successor . notify(n); </li></ul>
  19. 19. Notify() <ul><li>m thinks it might be n’s predecessor </li></ul><ul><li>n . notify (m) </li></ul><ul><li>if (predecessor is nil or m  (predecessor , n)) </li></ul><ul><li>predecessor = m; </li></ul>
  20. 20. Fix_fingers() <ul><li>Periodically called to make sure that finger table entries are correct </li></ul><ul><ul><li>New nodes initialize their finger tables </li></ul></ul><ul><ul><li>Existing nodes incorporate new nodes into their finger tables </li></ul></ul><ul><li>n .fi x _fi ngers () </li></ul><ul><li>next = next + 1 ; </li></ul><ul><li>if (next > m) </li></ul><ul><li>next = 1 ; </li></ul><ul><li>finger[next] = find_successor(n + 2 next -1 ); </li></ul>
  21. 21. Check_predecessor() <ul><li>Periodically called to check whether predecessor has failed </li></ul><ul><ul><li>If yes, it clears the predecessor pointer, which can then be modified by notify() </li></ul></ul><ul><li>n . check _ predecessor () </li></ul><ul><li>if (predecessor has failed) </li></ul><ul><li>predecessor = nil; </li></ul>
  22. 22. Theorem 3 <ul><li>If any sequence of join operations is executed interleaved with stabilizations, then at some time after the last join the successor pointers will form a cycle on all nodes in the network </li></ul>
  23. 23. Stabilization Protocol <ul><li>Guarantees to add nodes in a fashion to preserve reach ability </li></ul><ul><li>By itself won’t correct a Chord system that has split into multiple disjoint cycles, or a single cycle that loops multiple times around the identifier space </li></ul>
  24. 24. Impact of Node Joins on Lookups <ul><li>Correctness </li></ul><ul><ul><li>If finger table entries are reasonably current </li></ul></ul><ul><ul><ul><li>Lookup finds the correct successor in O(log N) steps </li></ul></ul></ul><ul><ul><li>If successor pointers are correct but finger tables are incorrect </li></ul></ul><ul><ul><ul><li>Correct lookup but slower </li></ul></ul></ul><ul><ul><li>If incorrect successor pointers </li></ul></ul><ul><ul><ul><li>Lookup may fail </li></ul></ul></ul>
  25. 25. Impact of Node Joins on Lookups <ul><li>Performance </li></ul><ul><ul><li>If stabilization is complete </li></ul></ul><ul><ul><ul><li>Lookup can be done in O(log N) time </li></ul></ul></ul><ul><ul><li>If stabilization is not complete </li></ul></ul><ul><ul><ul><li>Existing nodes finger tables may not reflect the new nodes </li></ul></ul></ul><ul><ul><ul><ul><li>Doesn’t significantly affect lookup speed </li></ul></ul></ul></ul><ul><ul><ul><li>Newly joined nodes can affect the lookup speed, if the new nodes ID’s are in between target and target’s predecessor </li></ul></ul></ul><ul><ul><ul><ul><li>Lookup will have to be forwarded through the intervening nodes, one at a time </li></ul></ul></ul></ul>
  26. 26. Theorem 4 <ul><li>If we take a stable network with N nodes with correct finger pointers, and another set of up to N nodes joins the network, and all successor pointers (but perhaps not all finger pointers) are correct, then lookups will still take O(log N) time with high probability </li></ul>
  27. 27. Failure and Replication <ul><li>Correctness of the protocol relies on the fact of knowing correct successor </li></ul><ul><li>To improve robustness </li></ul><ul><ul><li>Each node maintains a successor list of ‘r’ nodes </li></ul></ul><ul><ul><li>This can be handled using modified version of stabilize procedure </li></ul></ul><ul><ul><li>Also helps higher-layer software to replicate data </li></ul></ul>
  28. 28. Theorem 5 <ul><li>If we use successor list of length r = O(log N) in a network that is initially stable, and then every node fails with probability ½, then with high probability find_successor returns the closest living successor to the query key </li></ul>
  29. 29. Theorem 6 <ul><li>In a network that is initially stable, if every node fails with probability ½, then the expected time to execute find_successor is O(log N) </li></ul>
  30. 30. Voluntary Node Departures <ul><li>Can be treated as node failures </li></ul><ul><li>Two possible enhancements </li></ul><ul><ul><li>Leaving node may transfers all its keys to its successor </li></ul></ul><ul><ul><li>Leaving node may notify its predecessor and successor about each other so that they can update their links </li></ul></ul>
  31. 31. Conclusion <ul><li>Efficient location of the node that stores a desired data item is a fundamental problem in P2P networks </li></ul><ul><li>Chord protocol solves it in a efficient decentralized manner </li></ul><ul><ul><li>Routing information: O(log N) nodes </li></ul></ul><ul><ul><li>Lookup: O(log N) nodes </li></ul></ul><ul><ul><li>Update: O(log 2 N) messages </li></ul></ul><ul><li>It also adapts dynamically to the topology changes introduced during the run </li></ul>
  32. 32. Future Work <ul><li>Using Chord to detect and heal partitions whose nodes know of each other. </li></ul><ul><ul><li>Every node should know of some same set of initial nodes </li></ul></ul><ul><ul><li>Nodes should maintain long-term memory of a random set of nodes that they have visited earlier </li></ul></ul><ul><li>Malicious set of Chord participants could present an incorrect view of the Chord ring </li></ul><ul><ul><li>Node n periodically asks other nodes to do a lookup for n </li></ul></ul>
  33. 33. <ul><li>THANK YOU </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×