Chord advanced issues l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 25

Chord Advanced issues PowerPoint PPT Presentation

Chord Advanced issues Analysis Search takes O(log(N)) time Proof 1 (intuition): At each step, distance between query and peer hosting the object reduces by a factor of at least 2 Takes at most m steps: is at most a constant multiplicative factor above N, lookup is O(log(N))

Download Presentation

Chord Advanced issues

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Chord advanced issues l.jpg

Chord

Advanced issues


Analysis l.jpg

Analysis

Search takes O(log(N)) time

  • Proof 1 (intuition):At each step, distance between query and peer hosting the object reduces by a factor of at least 2

    Takes at most m steps: is at most a constant multiplicative factor above N, lookup is O(log(N))

  • Proof 2 (intuition):After log(N) forwarding steps, distance to key is at most Number of node identifiers in a range of is O(log(N)) with high probability (why? SHA-1!) So using successors in that range will be ok


Analysis contd l.jpg

Analysis (contd.)

  • O(log(N)) search time is true only if finger and successor entries correct

  • When might these entries be wrong?


Analysis contd4 l.jpg

Analysis (contd.)

  • O(log(N)) search time is true only if finger and successor entries correct

  • When might these entries be wrong?

    • When you have failures


Search under peer failures l.jpg

Search under peer failures

Lookup for K42 fails

(N16 does not know N45)

Say m=7

0

N16

N112

X

N96

X

N32

Who has abcnews.com?

(hashes to K42)

X

N45

N80

File abcnews.com with

key K42 stored here


Search under peer failures6 l.jpg

Search under peer failures

One solution: maintain r multiple successor entries

in case of failure, use other successor entries

Say m=7

0

N16

N112

N96

X

N32

Who has abcnews.com?

(hashes to K42)

N45

N80

File abcnews.com with

key K42 stored here


Search under peer failures7 l.jpg

Search under peer failures

  • Choosing r=2log(N) suffices to maintain correctness with high probability

    • Say 50% of nodes fail (i.e prob of failure = 1/2)

    • Pr(for given node, at least one successor alive)=

    • Pr(above is true for all alive nodes)=


Search under peer failures 2 l.jpg

Search under peer failures (2)

Lookup fails

(N45 is dead)

Say m=7

0

N16

N112

N96

N32

Who has abcnews.com?

(hashes to K42)

X

X

N45

N80

File abcnews.com with

key K42 stored here


Search under peer failures 29 l.jpg

Search under peer failures (2)

One solution: replicate file/key at r successors and predecessors

Say m=7

0

N16

N112

N96

N32

Who has cnn.com/index.html?

(hashes to K42)

K42 replicated

X

N45

N80

File cnn.com/index.html with

key K42 stored here

K42 replicated


Need to deal with dynamic changes l.jpg

Need to deal with dynamic changes

  • Peers fail

  • New peers join

  • Peers leave

    Need to update successors and fingers, and ensure keys reside in the right places


New peers joining l.jpg

New peers joining

Some gateway node directs N40 to N32

N32 updates successor to N40

N40 initializes successor to N45, and obtains fingers from it

N40 periodically talks to neighbors to update finger table

Say m=7

0

Stabilization

protocol

N16

N112

N96

N32

N40

N45

N80


New peers joining 2 l.jpg

New peers joining (2)

N40 may need to copy some files/keys from N45

(files with fileid between 32 and 40)

Say m=7

0

N16

N112

N96

N32

N40

N45

N80

K34,K38


Concurrent join l.jpg

Concurrent join

0

N16

N112

N20

Say m=7

N24

N96

N28

N32

K24

N80

N45

K38

Argue that each node will eventually be reachable


Stabilization protocol l.jpg

Stabilization Protocol

Concurrent peer joins, leave, or failure might cause the invariant to be violated, causing loopiness (?) or failure of lookups

  • periodically a stabilization algorithm checks and updates pointers and keys. [TechReport on Chord in the list of readings] defines weak and strong stability

  • Ensures non-loopiness of fingers, eventual success of lookups and O(log(N)) lookups w.h.p.


Effect on lookup l.jpg

Effect on lookup

If in a stable network with N nodes, another set of N nodes joins, and the join protocol correctly sets their successors, then lookups will take O(log N) steps w.h.p


Effect on lookup16 l.jpg

Effect on lookup

Consistent hashing

guarantees that there

be O(log N) new nodes

w.h,p between two

consecutive nodes

0

N16

N112

N20

Transfer pending

N96

N24

Linear Scan

Will locate

K24

N28

K24

N32

N80

N45

K38


Loopy network l.jpg

Loopy network

N1

(succ (pred (u))) = u

N3

N96

N5

stable

N78

N24

Must be false

for strong stability

N63

What is funny / awkward about this?

 v: u < v < successor (u)

(Weakly stable)


Weak and strong stabilization l.jpg

Weak and Strong Stabilization

N1

Loopy network

N3

N96

N5

N78

N24

N63

  • u (successor (predecessor (u))) = u. Still

    it is weakly stable but not strongly stable.


Strong stabilization l.jpg

Strong stabilization

  • The key idea of the algorithm is:Let each node u ask its

  • successor to walk around the ring until it reaches a node

  • v : u <v ≤ successor(u). If

    • v: u <v < successor(u)

      then loopiness exists, and reset successor(u):=v

      Takes O(N2) steps. But loopiness is a rare event.

      No protocol for recovery exists from a split ring.


New peers joining 3 l.jpg

New peers joining (3)

  • A new peer affects O(log(N)) other finger entries in the system. So, the number of messages per peer join= O(log(N)*log(N))

  • Similar set of operations for dealing with peers leaving


Slide21 l.jpg

Cost of lookup

  • Cost is O(Log N) as predicted by theory

  • constant is 1/2

Average Messages per Lookup

Number of Nodes


Slide22 l.jpg

Robustness

  • Simulation results: static scenario

  • Failed lookup means original node with key failed (no replica of keys)

  • Result implies good balance of keys among nodes!


Slide23 l.jpg

Strengths

  • Based on theoretical work (consistent hashing)

  • Proven performance in many different aspects

    • “with high probability” proofs

  • Good tolerance to random node failures


Slide24 l.jpg

Weakness

  • Member join & leave are complicated

    • aggressive mechanisms requires too many messages and updates

    • no analysis of convergence in lazy finger mechanism

  • Key management mechanism mixed between layers

    • upper layer does insertion and handle node failures

    • Chord transfer keys when node joins (no leave mechanism!)

  • Routing table grows with # of members in group

  • Worst case lookup can be slow


Slide25 l.jpg

Discussions

  • Network proximity (can we factor in latency?)

  • Protocol security

    • Malicious data insertion

    • Malicious Chord table information

  • Keyword search

  • ...


  • Login