DHT (continued) 2019-03-27 Recap 0 N16 N112 Nodes arranged in a - - PowerPoint PPT Presentation

▶
dht continued
SMART_READER_LITE
LIVE PREVIEW

DHT (continued) 2019-03-27 Recap 0 N16 N112 Nodes arranged in a - - PowerPoint PPT Presentation

Sep 22, 2023 28 likes •199 views

DHT (continued) 2019-03-27 Recap 0 N16 N112 Nodes arranged in a ring with positions labeled 0..2 m -1 N96 m = 128, 160, 256 m=7 A nodes position is based on a hash of its N32 identity P(collision among N nodes) =~ 1-e

slide-1
SLIDE 1

DHT (continued)

2019-03-27

slide-2
SLIDE 2

Recap

  • Nodes arranged in a ring with positions

labeled 0..2m-1

  • m = 128, 160, 256
  • A node’s position is based on a hash of its

identity

  • P(collision among N nodes) =~ 1-e-n(n-1)/2^(m+1)
  • For m=128, N=1,000,000,000, this is ~=

0.000000000000000000001469…

2019-03-27

N80 N112 N96 N16 N32 N45

m=7

slide-3
SLIDE 3

Recap

  • Nodes arranged in a ring with positions

labeled 0..2m-1

  • A node’s position is based on a hash of

its identity

  • A key x is stored at node with first

position greater than x on the ring

  • Each node stores approximately 1/N of all

keys

2019-03-27

N80 N112 N96 N16 N32 N45

m=7

File cnn.com/index.html with key K42 stored here

slide-4
SLIDE 4

Recap

  • Nodes arranged in a ring with positions

labeled 0..2m-1

  • A node’s position is based on a hash of

its identity

  • A key x is stored at node with first

position greater than x on the ring

  • A node’s fingers are based on id + 2i

(mod 2m) for i = 0, ..., m-1

  • Up to m fingers, though only O(log N)

distinct on average

2019-03-27

N80 N112 N96 N16 N32 N45

m=7

80 + 21 80 + 22 80 + 23 80 + 24 80 + 25

slide-5
SLIDE 5

Recap

  • Nodes arranged in a ring with positions

labeled 0..2m-1

  • A node’s position is based on a hash of its

identity

  • A key x is stored at node with first position

greater than x on the ring

  • A node’s fingers are based on id + 2i (mod

2m) for i = 0, ..., m-1

  • Search for key x proceeds by using largest

finger that makes progress towards key

2019-03-27

N80 N112 N96 N16 N32 N45

m=7

slide-6
SLIDE 6

2019-03-27

Analysis

Search takes O(log(N)) time

Proof

  • (intuition): at each step, distance between query and peer-

with-file reduces by a factor of at least 2 (why?) Takes at most m steps: 2m is at most a constant multiplicative factor above N, lookup is O(log(N))

  • (intuition): after log(N) forwardings, distance to key is at

most 2m / N (why?) Number of node identifiers in a range of 2m / N is O(log(N)) with high probability (why?) So using successors in that range will be ok Here Next hop Key

slide-7
SLIDE 7

Analysis (contd.)

  • O(log(N)) search time holds for file insertions too (in general for

routing to any key)

  • “Routing” can thus be used as a building block for
  • All operations: insert, lookup, delete
  • O(log(N)) time true only if finger and successor entries correct
  • When might these entries be wrong?
  • When you have failures

2019-03-27

slide-8
SLIDE 8

Search under peer failures

2019-03-27

N80 Say m=7 N32 N45 File cnn.com/index.html with key K42 stored here

X

X X Lookup fails (N16 does not know N45) N112 N96 N16 Who has cnn.com/index.html? (hashes to K42)

slide-9
SLIDE 9

Search under peer failures

2019-03-27

N80 Say m=7 N32 N45 File cnn.com/index.html with key K42 stored here

X

One solution: maintain r multiple successor entries In case of failure, use successor entries N112 N96 N16 Who has cnn.com/index.html? (hashes to K42)

slide-10
SLIDE 10

Search under peer failures (2)

2019-03-27

N80 Say m=7 N32 N45 File cnn.com/index.html with key K42 stored here

X

X Lookup fails (N45 is dead) N112 N96 N16 Who has cnn.com/index.html? (hashes to K42)

slide-11
SLIDE 11

2019-03-27

Search under peer failures (2)

N80 Say m=7 N32 N45 File cnn.com/index.html with key K42 stored here

X

One solution: replicate file/key at r successors and predecessors N112 N96 N16 K42 replicated K42 replicated Who has cnn.com/index.html? (hashes to K42)

slide-12
SLIDE 12

Need to deal with dynamic changes

üPeers fail

  • New peers join
  • Peers leave
  • P2P systems have a high rate of churn (node join, leave and failure)

à Need to update successors and fingers, and copy keys

2019-03-27

slide-13
SLIDE 13

2019-03-27

New peers joining

N80 Say m=7 N32 N45 N112 N96 N16 N40 Introducer directs N40 to N45 (and N32) N32 updates successor to N40 N40 initializes successor to N45, and inits fingers from it

slide-14
SLIDE 14

2019-03-27

New peers joining

N80 Say m=7 N32 N45 N112 N96 N16 N40 Introducer directs N40 to N45 (and N32) N32 updates successor to N40 N40 initializes successor to N45, and inits fingers from it N40 periodically talks to its neighbors to update finger table Stabilization Protocol (to allow for “continuous” churn, multiple changes)

slide-15
SLIDE 15

Lookups

2019-03-27

Average Messages per Lookup Number of Nodes

log N, as expected

slide-16
SLIDE 16

Chord Protocol: Summary

  • O(log(N)) memory and lookup costs
  • Hashing to distribute filenames uniformly across key/address space
  • Allows dynamic addition/deletion of nodes

2019-03-27

slide-17
SLIDE 17

DHT Deployment

  • Many DHT designs
  • Chord, Pastry, Tapestry, Koorde, CAN, Viceroy, Kelips, Kademlia, …
  • Slow adoption in real world
  • Most real-world P2P systems unstructured
  • No guarantees
  • Controlled flooding for routing
  • Kademlia slowly made inroads, now used in many file sharing networks
  • Distributed key-value stores adopt some of the ideas of DHTs
  • Dynamo, Cassandra, etc.

2019-03-27