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 MIT and Berkeley present ed by Daniel Figueiredo � pr esent at ion based on slides by Rober t Mor r is (SI GCOMM’01)

Out line Out line � Mot ivat ion and background � Consist ency caching � Chord � Perf ormance evaluat ion � Conclusion and discussion

Mot ivat ion Mot ivat ion How t o f ind dat a in a dist ribut ed f ile sharing syst em? N 2 N 3 N 1 Publisher Key= “LetItBe” Value= MP3 data Internet N 5 Client ? N 4 Lookup(“LetItBe”) � Lookup is t he key problem

Cent ralized Solut ion Cent ralized Solut ion � Cent ral server (Napst er) N 2 N 3 N 1 Publisher Key= “LetItBe” Value= MP3 data Internet DB N 5 Client N 4 Lookup(“LetItBe”) � Requires O(M) st at e � Single point of f ailure

Dist ribut ed Solut ion (1) Dist ribut ed Solut ion (1) � Flooding (Gnut ella, Morpheus, et c.) N 2 N 3 N 1 Publisher Key= “LetItBe” Value= MP3 data Internet N 5 Client N 4 Lookup(“LetItBe”) � Worst case O(N) messages per lookup

Dist ribut ed Solut ion (2) Dist ribut ed Solut ion (2) � Rout ed messages (Freenet , Tapest ry, Chord, CAN, et c.) N 2 N 3 N 1 Publisher Key= “LetItBe” Value= MP3 data Internet N 5 Client N 4 Lookup(“LetItBe”) � Only exact mat ches

Rout ing Challenges Rout ing Challenges � 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 Aut hors claim: � Chord: emphasizes ef f iciency and simplicit y

Chord Overview Chord Overview � 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?

Chord propert ies Chord propert ies � 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

Chord I Ds Chord I Ds � m bit ident if ier space f or bot h keys and nodes � Key ident if ier = SHA-1(key) SHA-1 Key= “LetItBe” ID= 60 � Node ident if ier = SHA-1(I P address) SHA-1 IP= “ 198.10.10.1” ID= 123 � Bot h are unif ormly dist ribut ed � How t o map key I Ds t o node I Ds?

Consist ent Hashing [Karger 97] Consist ent Hashing [Karger 97] K5 0 IP= “ 198.10.10.1” N123 K20 Circular 7-bit K101 N32 ID space Key= “LetItBe” N90 K60 � A key is st or ed at it s successor : node wit h next higher I D

Consist ent Hashing Consist ent Hashing � 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) 0 N10 Where is “LetItBe”? Hash(“LetItBe” ) = K60 N123 N32 “ N90 has K60” K60 N90 N55

Chord: Basic Lookup Chord: Basic Lookup � Every node knows it s successor in t he ring 0 N10 Where is “LetItBe”? N123 Hash(“LetItBe” ) = K60 N32 “ N90 has K60” N55 K60 N90 � requires O(N) t ime

“ Finger Tables” “ Finger Tables” � Every node knows m ot her nodes in t he ring � I ncrease dist ance exponent ially N16 N112 80 + 2 5 80 + 2 6 N96 80 + 2 4 80 + 2 3 80 + 2 2 80 + 2 1 80 + 2 0 N80

“ Finger Tables” “ Finger Tables” � Finger i point s t o successor of n+2 i N120 N16 N112 80 + 2 5 80 + 2 6 N96 80 + 2 4 80 + 2 3 80 + 2 2 80 + 2 1 80 + 2 0 N80

Lookups are Fast er Lookups are Fast er � Lookups t ake O(Log N) hops N5 N10 N110 K19 N20 N99 N32 Lookup(K19) N80 N60

J oining t he Ring J oining t he Ring � 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

J oining t he Ring - St ep 1 J oining t he Ring - St ep 1 � 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 N5 N20 N99 N36 1. Lookup(37,38,40,…,100,164) N40 N80 N60

J oining t he Ring - St ep 2 J oining t he Ring - St ep 2 � 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 N5 N20 N99 N36 N40 N80 N60

J oining t he Ring - St ep 3 J oining t he Ring - St ep 3 � Transf er keys f rom successor node t o new node � only keys in t he r ange ar e t r ansf er r ed N5 N20 N99 K30 N36 Copy keys 21..36 from N40 to N36 N40 K30 K38 N80 K38 N60

Handing Failures Handing Failures � Failure of nodes might cause incorrect lookup N120 N10 N113 N102 Lookup(90) N85 N80 � 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

Handling Failures Handling Failures � 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

Evaluat ion Overview Evaluat ion Overview � 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 of lookup Cost of lookup � Cost is O(Log N) as predict ed by t heory � const ant is 1/ 2 Average Messages per Lookup Number of Nodes

Robust ness Robust ness � 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!

Robust ness Robust ness � 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)

Current implement at ion Current implement at ion � 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 (?)

St rengt hs St rengt hs � 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 ?)

Weakness Weakness � 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

Discussions Discussions � 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 � ...