Chor d: A Scalable Peer-t o-peer Lookup Chor d: A Scalable Peer-t - - PowerPoint PPT Presentation
Chor d: A Scalable Peer-t o-peer Lookup Chor d: A Scalable Peer-t o-peer Lookup Ser vice f or I nt er net Applicat ions Ser vice f or I nt er net Applicat ions Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan
pr esent at ion based on slides by Rober t Mor r is (SI GCOMM’01)
Lookup is t he key problem
Publisher Key= “LetItBe” Value= MP3 data Lookup(“LetItBe”)
Client ?
Requires O(M) st at e Single point of f ailure
Publisher Key= “LetItBe” Value= MP3 data Lookup(“LetItBe”)
Client
Cent ral server (Napst er)
Worst case O(N) messages per lookup
Publisher Key= “LetItBe” Value= MP3 data Lookup(“LetItBe”)
Client
Flooding (Gnut ella, Morpheus, et c.)
Rout ed messages (Freenet , Tapest ry, Chord, CAN, et c.)
Publisher Key= “LetItBe” Value= MP3 data Lookup(“LetItBe”)
Client
Only exact mat ches
Def ine a usef ul key nearness met ric Keep t he hop count small Keep t he rout ing t ables “ right size” St ay robust despit e rapid changes in membership
Chord: emphasizes ef f iciency and
Provides peer-t o-peer hash lookup service:
Lookup(key) → I P address Chord does not st ore t he dat a
How does Chord locat e a node? How does Chord maint ain rout ing t ables? How does Chord cope wit h changes in membership?
Ef f icient : O(Log N) messages per lookup N is t he t ot al number of servers Scalable: O(Log N) st at e per node Robust : survives massive changes in membership Proof s are in paper / t ech report Assuming no malicious part icipant s
m bit ident if ier space f or bot h keys and nodes Key ident if ier = SHA-1(key)
Key= “LetItBe” ID= 60
SHA-1
IP= “ 198.10.10.1” ID= 123
SHA-1
Node ident if ier = SHA-1(I P
Bot h are unif ormly dist ribut ed How t o map key I Ds t o node I Ds?
A key is st or ed at it s successor : node wit h next higher I D
IP= “ 198.10.10.1”
Key= “LetItBe”
Ever y node knows of ever y ot her node requires global inf ormat ion Rout ing t ables ar e lar ge O(N) Lookups are f ast O(1)
N32 N90 N123
Hash(“LetItBe” ) = K60
N10 N55 Where is “LetItBe”?
“ N90 has K60”
K60
Hash(“LetItBe” ) = K60
“ N90 has K60”
Every node knows it s successor in t he ring requires O(N) t ime
Every node knows m ot her nodes in t he ring I ncrease dist ance exponent ially
80 + 20
80 + 21 80 + 22 80 + 23 80 + 24 80 + 25 80 + 26
Finger i point s t o successor of n+2i
80 + 20
80 + 21 80 + 22 80 + 23 80 + 24 80 + 25 80 + 26
Lookups t ake O(Log N) hops
N32 N10 N5 N20 N110 N99 N80 N60
Lookup(K19) K19
Three st ep process:
I nit ialize all f ingers of new node Updat e f inger s of exist ing nodes Tr ansf er keys f r om successor t o new node
Less aggressive mechanism (lazy f inger updat e):
I nit ialize only t he f inger t o successor node Periodically verif y immediat e successor, predecessor Per iodically r ef r esh f inger t able ent r ies
I nit ialize t he new node f inger t able
Locat e any node p in t he r ing Ask node p t o lookup f inger s of new node N36 Ret urn result s t o new node
N36
N60 N40 N5 N20 N99 N80
Updat ing f ingers of exist ing nodes
new node calls updat e f unct ion on exist ing nodes exist ing nodes can r ecur sively updat e f inger s of ot her
nodes
N36 N60 N40 N5 N20 N99 N80
Transf er keys f rom successor node t o new node
Copy keys 21..36 from N40 to N36 K30 K38
N36 N60 N40 N5 N20 N99 N80
K30 K38
Failure of nodes might cause incorrect lookup
N120 N113 N102 N80 N85 N10
Lookup(90)
N80 doesn’t know cor r ect successor , so lookup f ails Successor f inger s ar e enough f or cor r ect ness
Use successor list
Each node knows r immediat e successor s Af t er f ailur e, will know f ir st live successor Cor r ect successor s guar ant ee cor r ect lookups
Guarant ee is wit h some probabilit y
Can choose r t o make pr obabilit y of lookup f ailur e
arbit rarily small
Quick lookup in large syst ems Low variat ion in lookup cost s Robust despit e massive f ailure Experiment s conf irm t heoret ical result s
Cost is O(Log N) as predict ed by t heory
const ant is 1/ 2
Number of Nodes Average Messages per Lookup
Simulat ion r esult s: st at ic scenar io Failed lookup means or iginal node wit h key f ailed (no r eplica of keys) Result implies good balance of keys among nodes!
Simulat ion r esult s: dynamic scenar io Failed lookup means f inger pat h has a f ailed node 500 nodes init ially average st abilize( ) call 30s 1 lookup per second (Poisson) x j oin/ f ail per second (Poisson)
Chord library: 3,000 lines of C++ Deployed in small I nt ernet t est bed I ncludes: Correct concurrent j oin/ f ail Proximit y-based rout ing f or low delay (?) Load cont rol f or het erogeneous nodes (?) Resist ance t o spoof ed node I Ds (?)
Based on t heoret ical work (consist ent hashing) Proven perf ormance in many dif f erent aspect s
“ wit h high probabilit y” proof s
Robust (I s it ?)
NOT t hat simple (compared t o CAN) Member j oining is complicat ed
aggr essive mechanisms r equir es t oo many messages and updat es no analysis of conver gence in lazy f inger mechanism
Key management mechanism mixed bet ween layers
upper layer does inser t ion and handle node f ailur es Chor d t r ansf er keys when node j oins (no leave mechanism!)
Rout ing t able grows wit h # of members in group Worst case lookup can be slow
Net work proximit y (consider lat ency?) Prot ocol securit y
Malicious dat a inser t ion Malicious Chor d t able inf or mat ion
Keyword search and indexing ...