Ion Stoica, Robert Morris, David Karger,M. Frans Kaashoek, Hari Balakrishnan

MIT and Berkeley

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

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

OutlineOutline

Motivazioni

Consistent hashing

Chord

Valutazione delle prestazioni

Conclusioni e Discussioni

MotivazioniMotivazioni

Come trovare dati in un sistema distribuito di File Sharing?

il Lookup è il problema fondamentale

Internet

PublisherKey=“LetItBe”

Value=MP3 data

Lookup(“LetItBe”)

N1

N2 N3

N5N4Client ?

Solutioni DecentralizzateSolutioni Decentralizzate Routing di messaggi (Freenet, Tapestry, Chord, CAN,…)

Internet

PublisherKey=“LetItBe”

Value=MP3 data

Lookup(“LetItBe”)

N1

N2 N3

N5N4Client

matching esatto !?!?!

RoutingRouting

Definire una metrica (utile!!!!)

Mantenere basso il numero di hop

Mantenere bassa la dimensione della tabella di routing

Mantenere le caratteristiche in presenza di una variazione rapida del numero di nodi

Per gli autori: Chord: efficienza e semplicità

Chord OverviewChord Overview

Fornisce un servizio di lookup peer-to-peer:

Lookup(key) Indirizzo IP

Chord non memorizza dati

Come trova un nodo?

Come mantiene le tabelle di routing ?

Come gestisce l’ingresso e la uscita di nodi?

Caratteristiche di ChordCaratteristiche di Chord

Efficiente: O(Log N) messaggi per lookup

N è il numero totale di nodi presenti

Scalabile: O(Log N) stati per nodo

Robusto: mantiene le performance anche in presenza di variazioni notevoli del numero di nodi.

Assume che non ci siano partecipanti maliziosi

Identificatori in ChordIdentificatori in Chord

spazio degli identificatori a m bit sia per le

risorse (Chiavi) che per i nodi

identificatore di Chiave = SHA-1(Chiave)chiave=“LetItBe” ID=60SHA-1

IP=“198.10.10.1” ID=123SHA-1

identificatore di Nodo = SHA-1(indirizzo IP)

Entrambi sono distribuiti uniformemente

Come si associano gli ID di Chiave agli ID di nodo?

Consistent Hashing [Karger 97]Consistent Hashing [Karger 97]

Una chiave (risorsa) è memorizzata nel primo nodo che segue in senso orario

32

90

123 20

5

ID a 7-bit

0IP=“198.10.10.1”

101

60Chiave=“LetItBe”

Consistent HashingConsistent Hashing

Consistent HashingConsistent Hashing

Le funzioni Hash mappano chiavi in interi. Sono utilizzate, ad es, per memorizzare dati in un pool di cache

Con p cache una possibile funzione è

x -> ax+b (mod p)

Cosa accade se varia p ?

Se la usassimo in un sistema P2P ?

Consistent HashingConsistent Hashing

In particolare se varia p: è assicurato un Bilanciamento sul numero di dati per posizione Molti dati devono cambiare posizione Il numero di posizioni che un dato può potenzialmente raggiungere non è limitato

Consistent HashingConsistent Hashing

Per definizione un Consistent Hashing deve godere di opportune proprietà:

Bilanciamento Monotonicità Spread Carico

Consistent HashingConsistent Hashing

Bilanciamento:

Per ogni sottoinsieme V di posizioni (nodi) ed n dati, il numero di dati per ogni posizione è O(n/|V|) con alta probabilità.

Monotonicità:

Se al variare di p le posizioni (i nodi) disponibili passano da V1 a V2 con V1 V2, la migrazione dei dati deve avvenire solo verso posizioni appartenenti a V2 , ma non a V1 .

Consistent HashingConsistent Hashing

Spread:

Al variare di p il numero di posizioni che un dato può assumere è limitato.

Carico:

Al variare di p il numero di dati che una posizione accoglie è limitato.

Consistent HashingConsistent Hashing Funzioni Hashing Consistenti esistono ?

Siano K(x) ed N(x) due funzioni casuali che hanno come codominio l’intervallo [0,1).

Definiamo la seguente funzione Hash: Utilizziamo K(x) per mappare le chiavi Utilizziamo N(x) per mappare i nodi

La chiave i viene memorizzata nel nodo j se la differenza

|K(i)-N(j)| è la minima su tutti i nodi j.

Consistent HashingConsistent Hashing

0 1

Bilanciamento ? Monotonicità ? Spread ? Carico ?

LookupLookup Supponiamo che ogni nodo ha informazioni su tutti gli altri

richiede informazini globali Tabelle di routing O(N) la Lookup O(1)

32

90

123

0

Hash(“LetItBe”) = 60

10

55

Dove è “LetItBe”?

“90 ha 60”

60

Chord: Lookup di BaseChord: Lookup di Base

32

90

123

0

Hash(“LetItBe”) = 60

10

55

Dove è “LetItBe”?

“90 ha 60”

60

Ogni nodo conosce il successore

La Lookup O(N)

Tavola dei FingerTavola dei Finger

Ogni nodo conosce altri m nodi nell’anello

la distanza cresce esponenzialmente

8080 + 20

112

96

16

80 + 21

80 + 22

80 + 23

80 + 24

80 + 25 80 + 26

Tavola dei FingerTavola dei Finger

il Finger i del nodo n punta alla posizione n+2i-1

Se non c’è, punta al nodo subito successivo

120

8080 + 20

112

96

16

80 + 21

80 + 22

80 + 23

80 + 24

80 + 25 80 + 26

Tavola dei FingerTavola dei Finger

01

2

3

4

15

14

13

11

12

89

10

7

6

5

141

210

successor(1)=1

0

successor(2)=3

successor(6)=6

successor(9)=9

successor(10)=13

successor(14)=15

6

9

successor(0)=0

01

2

3

4

15

14

13

11

12

89

10

7

6

5

141

210

0

6

9

i succ node

1 2 3

2 3 3

3 5 6

4 9 9

i succ node

1 10 13

2 11 13

3 13 13

4 1 1

i succ node

1 14 15

2 15 15

3 1 1

4 5 6

Algoritmo LookupAlgoritmo Lookup

01

2

3

4

15

14

13

11

12

89

10

7

6

5

14

i succ node

1 2 3

2 3 3

3 5 6

4 9 9

i succ node

1 10 13

2 11 13

3 13 13

4 1 1

i succ node

1 14 15

2 15 15

3 1 1

4 5 6

LookupLookup

Vale la seguente proprietà:

Per il protocollo Chord ad m bit in un qualunque intervallo di ID di ampiezza 2m/N, il numero di ID di nodi atteso è 1 e O(log N) con alta probabilità

LookupLookup

E’ possibile mostrare il seguente teorema:

Il numero di nodi che deve essere contattato per trovare un successore in una rete con N nodi è O(log N) con alta probabilità.

A partire da questo risultato si può affermare che il numero di Hop necessari per effettuare una query è O(log N)

LookupLookup

Supponiamo che il nodo n debba trovare il successore di k.

Sulla dase dell’algoritmo viene prima cercato l’immediato predecessore, chiamamolo p, di k e poi viene chiesto a p di cercare il successore di k

A tale scopo il nodo n contatta il più vicino predecessore di k a lui noto. Supponiamo il nodo sia f ≠ n e sia l’i-esimo finger per n.

Per definizione di finger, f è a distanza almeno 2i-1 da n.

Poichè l’(i+1)-esimo finger di n supera k, n è a distanza al più 2i da p ed f è a distanza al più 2i-1 da p.

La distanza tra il nodo che sta processando la query ed il predecessore p dimezza ad ogni passo.

LookupLookup

La Lookup impiega O(Log N) hop

32

10

5

20

110

99

80

60

Lookup(19)

19

LookupLookup

Poichè la distanza iniziale è al più 2m, in m passi raggiungiamo p

In log N passi la distanza tra il nodo che sta processando la chiave ed il nodo p si riduce a 2m /N.

Poichè le chiavi sono distribuite in maniera uniforme, il numero di chiavi in un intervallo di ampiezza 2m /N è O(log N) con alta probabilità.

Sono quindi necessari, con alta probabilità, altri O(log N) passi per raggiungere p e quindi il successore di p

JoinJoin

Processo in tre passi:

Inizializza tutti i finger dei nuovi nodi

Aggiorna i finger dei nodi esistenti

Trasferisci le chiavi dal successore ai nuovi nodi

lazy finger update:

Initializza solo i finger al nodo successore

Periodicamente verifica il successore ed il predecessore

Periodicamente rinfresca il contenuto della tavola dei finger

Joining the Ring - Step 1Joining the Ring - Step 1

Inizializza la nuova tavola dei finger

individua un nodo nella rete

Chiedi al nodo di di cercare i finger del nuovo nodo

Raccogli i risultati

36

1. Lookup(37,38,40,…,100,164)

60

40

5

2099

80

Joining the Ring - Step 2Joining the Ring - Step 2

Aggiorna i finger dei nodi esistenti

il nuovo nodo chiama una funzione di aggiornamento sui nodi esistenti

I nodi esistenti possono ricorsivamente aggiornare i finger di altri nodi

N36

N60

N40

N5

N20N99

N80

Joining the Ring - Step 3Joining the Ring - Step 3

Trasferisci le chiavi dal successore al nuovo nodo

Vengono trasferite solo le chiavi nel range

Copia le chiavi 21..36da 40 to 36

3038

36

60

40

5

2099

80

30

38

26.join(friend) -> 26.successor = 32

26.stabilize -> 32.notify(26)

21.stabilize -> 21.successor=26 -> 26.notify(21)

Join di un nodoJoin di un nodo

Analisi del protocolloAnalisi del protocollo

Vale il seguente lemma:

Se al tempo t esiste un arco tra p ed s, allora per ogni t’>t ci sara’ un arco tra p ed sPer induzione sul tempo.

Suppopniamo che dopo t avvenga una join. L’arco tra p ed s non viene toccato dalla join e quindi permane.

Supponiamo avvenga una stabilize.

Consideriamo il momento in cui il nodo p cambia successore da s ad a. Questo avviene perchè p ha contattato s ed s gli ha detto di a. Inoltre p<a<s.

Analisi del protocolloAnalisi del protocollo

s ha saputo di a ad un tempo precedente e questo può essere avvenuto solo perchè s è stato un successore diretto di a.

Per ipotesi induttiva se esisteva un arco (il successore) tra a ed s, esiste un arco tra a ed s in tutti gli istanti successivi.

In particolare nell’istante in cui p cambia il successore. Essendo p<a<s il cambiamento del successore di p non influisce in alcun modo sull’arco tra a ed s.

Inoltre anche dopo il cambiamento esiste un arco tra p ed s.

Analisi del protocolloAnalisi del protocollo

Tutti gli archi tra x ed y, che utilizzavano l’arco tra p ed s, erano tali che p ed s erano interni ad x y. Ma tutti i nodi aggiunti all’arco p s sono interni a p s ed a maggior ragione interni ad x y.

Se un nodo è capace di risolvere una query, sarà sempre capace di farlo in futuro

Ad un tempo prefissato dopo l’ultima join i puntatori al successare saranno corretti per tutti i nodi

Analisi del protocolloAnalisi del protocollo

E’ possibile mostrare il seguente teorema:

Se ogni operazione di join e` alternata con quella di stabilizzazione, allora dopo un fissato tempo dall’ultima join i puntatori al successore formano un ciclo su tutti i nodi della rete.

Analisi del protocolloAnalisi del protocollo

Se due nodi condividono il successore, uno dei due cambierà il puntatore al successore.

Il suo nuovo successore sarà più vicino del nodo cui puntava in precedenza.

Ogni operazione di stabilizzazione potrebbe richiedere al più n passi.

Dopo n2 passi siamo quindi certi che tutti i nodi puntano al successore ed i puntatori formano un unico ciclo con tutti i nodi.

Join di un nodoJoin di un nodo

E’ possibile mostrare il seguente teorema:

Se abbiamo una rete stabile con N nodi ed effettuiamo N join alla rete,

Se tutti i puntatori ai successori sono corretti,

Allora il Lookup di una risorsa avrà necessità di O(log N) hops con alta probabilità.

Join di un nodoJoin di un nodo

Se utilizziamo i vecchi finger arriviamo in O(log N) hops al vecchio predecessore della risorsa. Con alta probabilità tra due vecchi nodi ci saranno al più O(log N) nuovi nodi.

Se i successori dei nuovi nodi sono corretti, in al più O(log N) passi la risorsa sarà raggiunta.

Gestione dei FallimentiGestione dei Fallimenti

I fallimenti dei nodi possono causare lookup scorretti

120

113

102

80

85

10

Lookup(90)

80 non conosce il corretto successore e quindi il lookup fallisce

Gestione dei FallimentiGestione dei Fallimenti

Usa la lista dei successori

Ciascun nodo conosce r successori

Dopo il fallimento si utilizza il primo successore rimasto

Si correggono i successori per garantire un corretto lookup

La lookup è corretta con alta probabilità

r può essere scelto in modo da rendere la probabilità di fallimento della lookup arbitrariamente piccola.

ValutazioneValutazione

lookup veloci in sistemi di grandi dimensioni

Variazione contenuta del costo di lookup

Robusto rispetto a molti fallimenti

Gli Esperimenti confermano i risultati teorici

Costo del lookupCosto del lookup

il costo è O(Log N) come previsto dalla teoria

la costante è 1/2

Number of Nodes

Avera

ge M

ess

ag

es

per

Looku

p

Implementazioni attualiImplementazioni attuali

Libreria Chord: 3,000 linee di C++

Include:

concurrent join/fail

Proximity-based routing

controllo di carico per nodi eterogenei

Resistente a spoofed node IDs

ProPro

Based on theoretical work (consistent hashing)

Proven performance in many different aspects

“with high probability” proofs

Robust (Is it?)

ControContro

NON semplice (confrontato con CAN)

join è complicato

richiede molti messaggi ed aggiornamenti

il meccanismo di aggiornamento leggero non è chiaro con che velocità converge

La tabella di Routing cresce con il numero di nodi

Il caso peggiore di lookup può essere molto lento