Livio Torrero - Politecnico di Torino
Algoritmi per protocolli peer-to-peer
Reti strutturate: casi di studio
Livio Torrero ([email protected])
09/2009
Livio Torrero - Politecnico di Torino
CHORD
• CHORD realizza un DHT con le seguenti caratteristiche:
– Load balance: CHORD distribuisce uniformemente le chiavi fra
i nodi
– Scalabilità: le operazioni di lookup sono efficienti
• Richiedono O(log(N)) messaggi scambiati fra i nodi (N = #peer)
– Robustezza: CHORD è in grado d modificare dinamicamente le
routing table dei nodi per riflettere i mutamenti della rete (nodi
che entrano o escono)
• CHORD fornisce il metodo lookup(key) che ritorna
l’indirizzo IP del nodo responsabile per la chiave
• CHORD si basa sul consistent hashing
2
Livio Torrero - Politecnico di Torino
Consistent hashing in CHORD
•
Se N è il numero di nodi presenti sulla rete, al variare di N si
desidera che:
– Si garantisca l’uniformità della distribuzione delle chiavi sui nodi
– La quantità di dati da rimappare nel sistema sia bassa
•
Il consistent hashing organizza i nodi in un cerchio modulo
(m = #bit ID)
0
1
6
m=3 #bit chiave
2
4
3
•
L’algoritmo di hash usato è SHA1
•
Gli ID dei nodi sono i codici hash ottenuti dagli indirizzi IP
•
•
Gli ID delle chiavi sono i codici hash ottenuti dalle chiavi
NOTA: gli ID dei nodi e gli ID delle chiavi sono nello stesso spazio
3
Livio Torrero - Politecnico di Torino
CHORD: assegnazione delle chiavi (1/2)
• La chiave k è assegnata al primo nodo n sull’anello il cui
identificatore è uguale o maggiore all’identificatore di k
• La metrica di distanza in CHORD è la differenza lineare
• Si dice n=successor(k)
– n, il nodo responsabile di k è detto successore di k
– CHORD espone la chiamata find_successor per localizzarlo
4
Livio Torrero - Politecnico di Torino
CHORD: assegnazione delle chiavi (2/2)
•
La metrica di distanza è unidirezionale
– Data una distanza D e un nodo x, esiste un solo nodo y per cui d(x,y) = D
– Tutti i lookup per una stessa chiave convergono sullo stesso path
– E’ utile fare caching dei risultati dei lookup sui nodi intermedi
•
All’arrivo di un nuovo peer questi riceve alcune chiavi del nodo che lo
segue sull’anello
– Ora è il nuovo responsabile per quelle chiavi
– Es: cosa succede in figura se entrasse il nodo 7?
– 7 = successor(6) => la chiave 6 è spostata dal nodo 0 al nodo 7
5
Livio Torrero - Politecnico di Torino
CHORD: lookup scalabile (1/5)
• Per fare le ricerche ogni nodo in teoria ha bisogno solamente
di conoscere il nodo che segue
Dove si trova la
chiave 5?
0
Chiave 5
1
6
2
4
3
• CHORD assicura la validità di questi puntatori
• Tuttavia questo non è sufficiente per garantire prestazioni
accettabili
– Ricerca lineare
6
Livio Torrero - Politecnico di Torino
CHORD: lookup scalabile (2/5)
• Si supponga invece che il nodo abbia informazioni
su TUTTI gli altri nodi (routing table completa)
Dove si trova la
chiave 5?
0
Chiave 5
1
6
2
4
3
• Impraticabile: richiede N entry nella routing table!
– N = numero nodi nell’overlay!
7
Livio Torrero - Politecnico di Torino
CHORD: lookup scalabile (3/5)
• Per ottimizzare CHORD mantiene le finger table
– È una lista di nodi che forma una sorta di “routing table” del
peer
– Al più m nodi, a regime O(log(N)) distinti in finger table
• Ogni entry della finger table copre una porzione dello
spazio delle chiavi
• Ciascuna entry contiene un next hop a cui inoltrare la
richiesta per una chiave nello spazio coperto dalla
entry
8
Livio Torrero - Politecnico di Torino
CHORD: lookup scalabile (4/5)
• Io nodo interrogato sono il nodo responsabile per la chiave
cercata?
• Sì:
– Rispondo alla richiesta
• No:
– Determino la entry della finger table che copre l’intervallo
desiderato
– Inoltro all’host memorizzato come next hop nella entry la
richiesta
9
Livio Torrero - Politecnico di Torino
CHORD: lookup scalabile (5/5)
• Allontanandosi dal nodo gli intervalli sono sempre più grandi
– Ogni nodo è in grado di determinare con maggior precisione il nodo
responsabile di chiavi più vicine al suo identificatore
• Continuando a cercare sull’anello mi avvicino sempre più a nodi vicini
alla chiave cercata
10
Livio Torrero - Politecnico di Torino
CHORD: esempio di lookup
• Esempio:
• Nodo 3 vuole trovare chi gestisce la chiave 1 (= successor(1))
•
1 [7,3) : quindi 3 manda una query al nodo 0 (entry #3
della finger table)
• 1
[1,2): il nodo 0 conosce successor (1) e lo dice a 3
11
Livio Torrero - Politecnico di Torino
CHORD: join dei nodi
•
L’entrata o l’uscita dei nodi nell’overlay può avvenire in qualsiasi
momento
•
Perché tutto funzioni si DEVE garantire che:
– Il successore di ogni nodo sia noto
– Per ogni chiave k, successor(k) ne sia il responsabile
•
Inoltre è auspicabile che le finger table siano corrette
•
Al join, un nodo n deve:
– Inizializzare le entry della sua finger table
• Per ogni i calcola finger[i].start e lo fa cercare da un qualsiasi nodo della DHT
– Aggiornare le finger degli altri nodi inserendosi in esse se necessario
– Muovere sul nodo n tutte le chiavi di cui è responsabile
•
La join realizzata in questo modo è molto aggressiva.
•
In realtà si utilizza un algoritmo più leggero ma più complesso che
supporta join multiple simultanee
12
Livio Torrero - Politecnico di Torino
CHORD: uscita dei nodi
• L’uscita dei nodi si potrebbe trattare come una failure degli
stessi e non fare nulla
• Per ottimizzare, quando un nodo esce dall’overlay (graceful
leave):
– Trasferisce le chiavi di cui è responsabile al suo successore
– Aggiorna il puntatore al nodo che lo precede del nodo che lo
segue sull’anello
– Aggiorna il puntatore al nodo che lo segue del nodo che lo
precede sull’anello
13
Livio Torrero - Politecnico di Torino
Kademlia
• Sistema di lookup che utilizza una metrica di
distanza basata su XOR
• Date due chiavi x e y la loro distanza è
d(x,y)=x xor y
– Xor bit a bit
• Realizza una topologia ad albero basata sulla
metrica
• Kademlia utilizza query parallele asincrone
• Gli identifcatori delle risorse sono chiavi su 160 bit
(SHA-1)
14
Livio Torrero - Politecnico di Torino
Kademlia: binary tree
• Kademlia tratta i nodi come foglie di un albero binario
– La posizione di un nodo è determinata dal suo prefisso
univoco più corto
• Il primo sottoalbero a sinistra è la prima metà che non
contiene il nodo e così via, ricursivamente
• Kademlia garantisce che il nodo con prefisso univoco 000
conosca almeno un nodo in ciascuno degli altri
sottoalberi
15
Livio Torrero - Politecnico di Torino
Routing delle query in kademlia
• La routing table di ogni nodo in kademlia contiene almeno
un nodo di ogni sotto albero.
– Diversamente da Chord ogni entry della routing table contiene
più di un nodo
– Nodi della stessa entry appartengono al medesimo sottoalbero
– Conoscendo almeno un rappresentante per ogni sotto albero è
possibile raggiungere qualunque nodo sull’overlay
16
Livio Torrero - Politecnico di Torino
Kademlia: binary tree
•
Grazie alla conoscenza di tutti i sotto alberi ogni nodo può trovare
qualsiasi altro nodo dell’albero
•
Un nodo attraverso la sua routing table riesce a localizzare in una
serie di passaggi successivi qualsiasi nodo sull’albero in modo
ottimale
•
La routing table è organizzata come un insieme di k-bucket
17
Livio Torrero - Politecnico di Torino
Kademlia: metodi esportati
• Kademlia offre 4 funzioni:
– PING: verifica se un nodo è attivo
– STORE: memorizza la coppia <chiave, valore> nel nodo più
vicino alla chiave
•
STORE(chiave)
Le informazioni vengono replicate
<chiave, valore>
– FIND_NODE: data una chiave ritorna (IP, porta, NodeID)
per i k nodi più vicini alla chiave.
• I k nodi possono provenire da più k-bucket se il k-bucket più
vicino non è pieno
– FIND_VALUE: variante della precedente per ottenere un
valore data una chiave
18
Livio Torrero - Politecnico di Torino
Kademlia: memorizzare dati sull’overlay
• Procedura utilizzata per memorizzare nuovi dati nell’overlay
– Un nodo desidera memorizzare una entry contenente dati
sull’overlay
• Il nodo che vuole inserire nuovi dati, localizza i k nodi piu’
vicini alla chiave relativa ai dati da memorizzare
• Viene quindi eseguita una STORE su ciascuno di essi
• Ogni nodo che ha memorizzato una coppia chiave valore
ripubblica ogni coppia chiave/valore entro un ora
• L’originatore della coppia ripubblica la coppia ogni 24 ore
19
Livio Torrero - Politecnico di Torino
Confonto tra CHORD e Kademlia
• In CHORD la routing table è rigida
– Richiede costose operazioni per essere mantenuta in
caso di failure di un nodo
• Kademlia offre una routing table flessibile
– Metrica di distanza simmetrica oltre che
unidirezionale
– Esiste sempre più di un percorso alternativo
– Le ricerche sono parallelizzate
– La manutenzione della routing table è più bassa
– Le entry della routing table di Kademlia sono liste di
nodi: maggiore robustezza
• E’ possibile dimostrare che il numero di entry nella
routing table di Kademlia è logaritmico
20
Livio Torrero - Politecnico di Torino
Limiti delle DHT (1/3)
• I client p2p sono transienti per natura
– Il tempo di connessione media per un nodo è di 60min
• In Gnutella se un nodo perde tutti i vicini prova
semplicemente a riconnettersi
• Nelle DHT il problema è più grave (almeno in CHORD)
– L’uscita di un nodo graceful (=“annunciata”) comporta in
genere O(log(n)) operazioni per mantenere coerenti le
strutture dati
– Un uscita graceless (senza annuncio è trasferimento
preventivo di informazioni di stato) ha esiti peggiori
• Richiede tempo per:
– Rilevare la failure
– Replicare i dati persi dal peer disconnesso
21
Livio Torrero - Politecnico di Torino
Limiti delle DHT (2/3)
• Le ricerche di parole chiave sono più numerose delle
ricerche esatte
– Le DHT si prestano a ricerche esatte
• Dato il nome esatto di un file lo localizzano
– E’ possibile implementare richerche per parole chiave nelle
DHT, ma è costoso
– Le p2p non strutturate non hanno di questi problemi: perché le
ricerche si fanno sulla base di informazioni contenute nei
singoli nodi
• Le DHT trovano un ago in un pagliaio, i p2p non strutturati
no
– Gnutella non può garantire di poter trovare una singola copia
di un file a meno che la query non raggiunge tutti i nodi
22
Livio Torrero - Politecnico di Torino
Limiti delle DHT (3/3)
• Tuttavia la distribuzione delle richieste privilegia i file più
replicati
– Questo limita gli svantaggi delle reti non strutturate
23
