CHORD: A SCALABLE PEER-TO-PEERLOOKUP SERVICE FOR INTERNETAPPLICATIONS Ion Stoica                 Robert Morris David Liben...
INTRODUCTION A fundamental problem that confronts peer-to-peer  applications is to efficiently locate the node that  stor...
SYSTEM MODEL (FEATURES) Load balance: Chord acts as a distributed hash  function, spreading keys evenly over the nodes. t...
CONT… Scalability: The cost of a Chord lookup grows as  the log of the number of nodes, so even very large  systems are f...
THE BASE CHORD PROTOCOL   The Chord protocol specifies how to find the    locations of keys, how new nodes join the    sy...
OVERVIEW Chord provides fast distributed computation of a  hash function mapping keys to nodes responsible  for them. wh...
CONSISTENT HASHING Consistent hashing is designed to let nodes enter  and leave the network with minimal disruption. To ...
SCALABLE KEY LOCATION This scheme has two important characteristics. First, each node stores information about only a  s...
FINGER TABLE
NODE JOINS Initialize the predecessor and fingers of node n. Update the fingers and predecessors of existing  nodes to r...
IMPACT OF NODE JOINS ONLOOKUPS   Correctness       If finger table entries are reasonably current           Lookup find...
IMPACT OF NODE JOINS ON LOOKUPS Performance     If stabilization is complete         Lookup can be done in O(log N) tim...
STABILIZATION AFTER JOIN                                                                             n joins             ...
SOURCE OF INCONSISTENCIES:CONCURRENT OPERATIONS AND FAILURES   Basic “stabilization” protocol is used to keep nodes’ succ...
FAILURE RECOVERY   Key step in failure recovery is maintaining correct successor pointers   To help achieve this, each n...
SIMULATION   Protocol Simulator:     The Chord protocol can be implemented in an iterative      or recursive style.    ...
EXPERIMENTAL RESULTS   Latency grows slowly with the total    number of nodes   Path length for lookups is about ½    lo...
CONCLUSION Efficient          location of the node that stores a  desired data item is a fundamental problem in  P2P netw...
FUTURE WORK   Using Chord to detect and heal partitions whose    nodes know of each other.     Every node should know of...
REFERENCES   Chord: A Scalable Peer-to-Peer Lookup Service    for Internet Applications by Ion Stoica, Robert    Morris, ...
Upcoming SlideShare
Loading in …5
×

Chord- A Scalable Peer-to-Peer Lookup Service for Internet Applications

1,414 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,414
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
42
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Chord- A Scalable Peer-to-Peer Lookup Service for Internet Applications

  1. 1. CHORD: A SCALABLE PEER-TO-PEERLOOKUP SERVICE FOR INTERNETAPPLICATIONS Ion Stoica Robert Morris David Liben-Nowell David R. Karger M. Frans Kaashoek Frank Dabek Hari Balakrishnan Presented By- Chaitanya Pratap MCA(4th Semester) South Asian University, New Delhi.
  2. 2. INTRODUCTION A fundamental problem that confronts peer-to-peer applications is to efficiently locate the node that stores a particular data item. Chord provides support for just one operation: given a key, it maps the key onto a node. Data location can be easily implemented on top of Chord by associating a key with each data item, and storing the key/data item pair at the node to which the key maps.
  3. 3. SYSTEM MODEL (FEATURES) Load balance: Chord acts as a distributed hash function, spreading keys evenly over the nodes. this provides a degree of natural load balance. Decentralization: Chord is fully distributed: no node is more important than any other. This improves robustness.
  4. 4. CONT… Scalability: The cost of a Chord lookup grows as the log of the number of nodes, so even very large systems are feasible. Availability: Chord automatically adjusts its internal tables to reflect newly joined nodes as well as node failures, ensuring that the node responsible for a key can always be found. Flexible naming: Chord places no constraints on the structure of the keys it looks up: the Chord key- space is flat.
  5. 5. THE BASE CHORD PROTOCOL The Chord protocol specifies how to find the locations of keys, how new nodes join the system, and how to recover from the failure (or planned departure) of existing nodes.
  6. 6. OVERVIEW Chord provides fast distributed computation of a hash function mapping keys to nodes responsible for them. when an Nth node joins (or leaves) the network, only an O(1/N) fraction of the keys are moved to a different location A Chord node needs only a small amount of “routing” information about other nodes. In an N node network, each node maintains information only about O(log N) other nodes, and a lookup requires O(log N) messages. a join or leave requires O(log N^2) messages.
  7. 7. CONSISTENT HASHING Consistent hashing is designed to let nodes enter and leave the network with minimal disruption. To maintain the consistent hashing mapping when a node n joins the network, certain keys previously assigned to n’s successor now become assigned to n. When node n leaves the network, all of its assigned keys are reassigned to n’s successor.
  8. 8. SCALABLE KEY LOCATION This scheme has two important characteristics. First, each node stores information about only a small number of other nodes, it only knows about closer nodes. Second, a node’s finger table generally does not contain enough information to determine the successor of an arbitrary key.
  9. 9. FINGER TABLE
  10. 10. NODE JOINS Initialize the predecessor and fingers of node n. Update the fingers and predecessors of existing nodes to reflect the addition of n. Notify the higher layer software so that it can transfer state (e.g. values) associated with keys that node n is now responsible for.
  11. 11. IMPACT OF NODE JOINS ONLOOKUPS Correctness  If finger table entries are reasonably current  Lookup finds the correct successor in O(log N) steps  If successor pointers are correct but finger tables are incorrect  Correct lookup but slower  If incorrect successor pointers  Lookup may fail
  12. 12. IMPACT OF NODE JOINS ON LOOKUPS Performance  If stabilization is complete  Lookup can be done in O(log N) time  If stabilization is not complete  Existing nodes finger tables may not reflect the new nodes  Doesn’t significantly affect lookup speed  Newly joined nodes can affect the lookup speed, if the new nodes ID’s are in between target and target’s predecessor  Lookup will have to be forwarded through the intervening nodes, one at a time
  13. 13. STABILIZATION AFTER JOIN  n joins ns  predecessor = nil  n acquires ns as successor via some n’  n notifies ns being the new predecessor pred(ns) = n  ns acquires n as its predecessor  np runs stabilize  np asks ns for its predecessor (now n) n succ(np) = ns  np acquires n as its successor pred(ns) = np  np notifies n  n will acquire np as its predecessor succ(np) = n nil  all predecessor and successor pointers are now correct  fingers still need to be fixed, but old fingers will still work np 13
  14. 14. SOURCE OF INCONSISTENCIES:CONCURRENT OPERATIONS AND FAILURES Basic “stabilization” protocol is used to keep nodes’ successor pointers up to date, which is sufficient to guarantee correctness of lookups Those successor pointers can then be used to verify the finger table entries Every node runs stabilize periodically to find newly joined nodes 14
  15. 15. FAILURE RECOVERY Key step in failure recovery is maintaining correct successor pointers To help achieve this, each node maintains a successor-list of its r nearest successors on the ring If node n notices that its successor has failed, it replaces it with the first live entry in the list stabilize will correct finger table entries and successor-list entries pointing to failed node Performance is sensitive to the frequency of node joins and leaves versus the frequency at which the stabilization protocol is invoked 15
  16. 16. SIMULATION Protocol Simulator:  The Chord protocol can be implemented in an iterative or recursive style.  In the iterative style, a node resolving a lookup initiates all communication: it asks a series of nodes for information from their finger tables, each time moving closer on the Chord ring to the desired successor.  In the recursive style, each intermediate node forwards a request to the next node until it reaches the successor.  The simulator implements the protocols in an iterative style.
  17. 17. EXPERIMENTAL RESULTS Latency grows slowly with the total number of nodes Path length for lookups is about ½ log2N Chord is robust in the face of multiple node failures 17
  18. 18. CONCLUSION Efficient location of the node that stores a desired data item is a fundamental problem in P2P networks Chord protocol solves it in a efficient decentralized manner  Routing information: O(log N) nodes  Lookup: O(log N) nodes  Update: O(log2 N) messages Italso adapts dynamically to the topology changes introduced during the run
  19. 19. FUTURE WORK Using Chord to detect and heal partitions whose nodes know of each other.  Every node should know of some same set of initial nodes  Nodes should maintain long-term memory of a random set of nodes that they have visited earlier Malicious set of Chord participants could present an incorrect view of the Chord ring  Node n periodically asks other nodes to do a lookup for n
  20. 20. REFERENCES Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications by Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan.

×