Seminario: Algoritmi per Protocolli Peer-To-Peer

3/11/2006
Algoritmi per protocolli peer-to-peer
Netgroup – Politecnico di Torino
Livio Torrero – [email protected]
3/11/2006
Approccio client-server
Client 1
Client 3
Server
Client 2
Paradigma molto comune
Un client richiede dati o servizi, un server risponde
Scalabilità e affidabilità ottenuta attraverso
ridondanza e sistemi di supporto (DNS…)
2/72
Client 4
Single point of failure nel server
Richiede un amministratore di sistema per la
gestione
Esempi: Web, FTP…
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Paradigma peer-to-peer (1/2)
3/72
Peer 2
Peer 4
Specifica come si fa, non cosa
Può essere applicato in diversi contesti: file sharing, voip…
Non esistono nodi centrali, tutti i nodi hanno pari dignità
I nodi interagiscono direttamente per lo scambio delle
risorse
I nodi che mantengono la rete sono gli stessi che ne
usufruiscono
Peer 3
Il peer-to-peer è un paradigma
Peer 1
No single point of failure
Elevata scalabilità e affidabilità
Si adattano meglio a infrastrutture dinamiche
Sfruttano la maggiore potenza dei nuovi computer
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Overlay peer-to-peer
I peer si organizzano in un overlay:
L’overlay è una “rete sulla rete”
I peer si organizzano creando dei link virtuali fra loro
Normalmente nell’overlay esistono più copie della
stessa risorsa per massimizzarne la raggiungibilità
4/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Caratteristiche delle reti peer-to-peer
Tutti i nodi sono potenzialmente sia client
che server
I nodi in quanto tali non hanno le stesse
disponibilità di risorse di un server
tradizionale (banda…)
Alcuni peer hanno connettività limitata
(NAT, firewall…)
Le reti peer-to-peer sono reti di grandi
dimensioni
Potenzialmente
5/72
di dimensioni mondiali
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Peer-to-peer: operazioni
fondamentali
Un nodo p2p svolge le seguenti operazioni
di base:
BOOT:
è la fase di ingresso nella infrastruttura
peer-to-peer
Cache preesistenti
Configurazione statica
Nodi centralizzati di bootstrap
LOOKUP RISORSE: come localizzo le risorse su
una infrastruttura p2p?
SCAMBIO DI FILE: per queste operazioni tutti gli
algoritmi sono p2p puri
6/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Classificazione infrastrutture peer-to-peer
(tecniche di lookup):
approccio centralizzato
Infrastrutture peer-to-peer
Approccio centralizzato
Prime implementazioni di infrastrutture peer
Approccio ancora fortemente simile al client server
Basate su nodi fissi
7/72
Approccio decentralizzato
Colli di bottiglia => non scalano
Single point of failure => infrastruttura fragile
Napster è un esempio di approccio centralizzato
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Napster: introduzione
Nato come applicativo per lo scambio di file
musicali
Nel 1999 le major disocgrafiche fanno causa
a Napster => il bacino di utenza decolla
13,6
milioni di utenti nel febbraio 2001
Nel settembre 2001 viene ordinata la
chiusura di Napster
Napster si converte in servizio a pagamento
Nel 2002 chiude
8/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Funzionamento di Napster
Quando un nodo entra nell’infrastruttura si
registra presso il server
Upload
della lista delle risorse gestite
Peer
query
answer
Server centrale
In base ai risultati ottenuti il peer si
connette a un altro peer per scaricare la
risorsa
Peer
Server centrale
Dow
nload
Peer
9/72
Server centrale
Quando un nodo cerca una risorsa fa un
lookup sul server centralizzato
Peer
Upload
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Classificazione infrastrutture peer-to-peer
(tecniche di lookup):
approccio non centralizzato
Infrastrutture peer-to-peer
Approccio centralizzato
Implementazioni più evolute
Non c’è più un nodo di lookup centralizzato
Lookup distribuito e reti gerarchiche
Contro: maggiore complessità
10/72
Le informazioni di lookup sono distribuite direttamente
sui nodi
Pro: maggiore scalabilità
Approccio decentralizzato
Se non c’è più server centrale, come si trovano le
risorse?
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Approcci non centralizzati
Approccio decentralizzato
non strutturato
L’approccio non strutturato non fornisce un
controllo stretto sulla topologia della rete peer to
peer
Non esiste un directory service vero e proprio
Uso estensivo del flooding
Agenda:
11/72
strutturato
Gnutella: caso di studio
Kazaa: caso di studio
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Gnutella introduzione
Gnutella è un client p2p sviluppato nel 2000
da Justin Frankel e Tom Pepper di Nullsoft,
appena acquisita da AOL
Pare
sia stato scritto in 14 giorni…
In origine il codice sorgente doveva uscire
in formato GPL
Tuttavia attraverso tecniche di reverseengineering sono stati sviluppati numerosi
cloni open-source
Limewire
è software open-source che supporta la
rete Gnutella
12/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Gnutella: evoluzione
Originariamente tutti i nodi in Gnutella
erano uguali
I
peer erano detti servent
Tuttavia questo approccio non scalava
Fare
un flooding su tutti i nodi della rete non
funziona
Bisogna tenere conto del fatto che non tutti i nodi
sono uguali
Per meglio tenere conto delle caratteristiche
della rete Gnutella è stato riorganizzato
Il risultato è una rete gerarchica a 2 livelli
13/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Gnutella(limewire): rete gerarchica
leaf
leaf
leaf
ultrapeer
ultrapeer
ultrapeer
leaf
leaf
leaf
Es: nodi con connessioni dialup
Sono fuori dall’overlay (si connettono agli ultrapeer come
client)
Non accettano connessioni Gnutella
Se un nodo leaf vuole diventare ultrapeer, prima si
disconnette dalla rete per ripresentarsi tentando di diventare
ultrapeer
Ultrapeer
Fa da proxy per i nodi leaf
Un nodo ultrapeer deve avere una connessione Internet
veloce non bloccata da firewall
14/72
leaf
Nodi leaf
ultrapeer
limewire => upload 10kB/s, download 20kB/s
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Gnutella: overlay discovery
Un nodo per accedere all’overlay Gnutella deve
conoscere almeno un ultrapeer
Come scoprire altri nodi? Pong caching
Messaggio Ping (richiesta): chi lo riceve risponde
con un messaggio Pong
Messaggio Pong (risposta): contiene le informazioni
relative a un computer (IP + porta)
15/72
Le modalità con cui questo avviene non sono oggetto
di Gnutella
Solo gli ultrapeer mandano i pong
Quando un ultrapeer riceve dei messaggi pong li
mette nella sua pong cache
Quando un ultrapeer riceve un messaggio ping
risponde con tutti i pong nella sua cache
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Da nodo leaf a ultrapeer
I nodi decidono da soli se connettersi alla
rete come Ultra peer o nodi normali
Un
nodo DEVE restare leaf per un ora
ultrapeer
1h
leaf
ultrapeer
ultrapeer
ultrapeer
Poi
può tentare di connettersi a un ultrapeer
come ultrapeer
ultrapeer?
ultrapeer connect
ultrapeer
ultrapeer
ultrapeer
ultrapeer
Se
ultrapeer?
l’ultrapeer lo rifiuta, torna leaf per un’altra ora
Refuse connection
ultrapeer
ultrapeer
ultrapeer
ultrapeer
Leaf for 1h
leaf (!)
16/72
leaf connect
ultrapeer
ultrapeer
Algoritmi per protocolli peer-to-peer - Torrero
ultrapeer
ultrapeer
3/11/2006
I Connection Slot: organizzazione
delle connessioni in Gnutella
Un connection slot rappresenta la necessità di un
nodo di creare una connessione verso un altro o la
disponibilità ad accettare le connessioni
Un nodo leaf ha 3 connection slot verso gli Ultrapeer
Un ultrapeer si connetterà con al più 32 altri
ultrapeer
questo valore è detto network degree
Un ultrapeer ha 30 connection slot verso i nodi leaf
17/72
Creerà fino a 3 connessioni verso ultrapeer diversi
Un ultrapeer non permette a più di 30 nodi foglia di
connettersi a lui
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Gnutella handshake
Ogni connessione Gnutella comincia con un
handshake
Un
nodo accede all’overlay con un messaggio
GNUTELLA CONNECT che apre un socket TCP
I messaggi di handshake sono costituiti da
gruppi di header di formato simile ad HTTP
(testo ASCII)
Ogni
header è nella forma
<nome>:<valore1>,<valore2>…
Ogni gruppo inizia con una greeting line che
identifica il messaggio
18/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Esempi di handshake Gnutella(1/2)
Un nodo leaf si connette a un UltraPeer (connessione generica)
0.6 è la versione corrente di Gnutella
leaf
ultrapeer
GNUTELLA connect/0.6
X-Ultrapeer=false
GNUTELLA/0.6 200 OK
Un nodo leaf dietro un NAT si connette a un ultrapeer
Listen-IP indirizzo del peer che manda messaggio
Remote-IP indirizzo nodo leaf visto da UltraPeer
leaf
NAT
GNUTELLA connect/0.6
X-Ultrapeer=false
ultrapeer
217.254.98
.153
Un ultrapeer si connette a un ultrapeer
ultrapeer
GNUTELLA connect/0.6
X-Ultrapeer=true
19/72
GNUTELLA/0.6 200 OK
Listen-IP:68.37.233.44:9376
Remote-IP: 217.254.98.153
Algoritmi per protocolli peer-to-peer - Torrero
ultrapeer
GNUTELLA/0.6 200 OK
3/11/2006
Esempi di handshake Gnutella(2/2)
Un nodo si connette a un ultrapeer che rifiuta la connessione
L’ultrapeer deve fornire ultrapeer alternativi
Nodo Gnutella generico
ultrapeer
GNUTELLA connect/0.6
GNUTELLA/0.6 service unavailable
X-Try-Ultrapeers:68.37.233.44:9376,
172.195.105.218:3988…
Un nodo si connette a un ultrapeer che accetta e fornisce
indirizzi alternativi
È consigliato fornire altri ultrapeer a cui connettersi
Limewire ne fornsice 10
Nodo Gnutella generico
ultrapeer
GNUTELLA connect/0.6
GNUTELLA/0.6 200 OK
X-Try-Ultrapeers:68.37.233.44:9376,
172.195.105.218:3988…
20/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Lookup in Gnutella: introduzione
L’algoritmo di lookup è il dynamic querying
Obiettivo:
localizzare una risorsa con il minor
numero di messaggi possibile
Viene eseguito solo dagli ultrapeer
Si articola in 3 fasi:
“Search our leaves”
“Probe Query”
“Controlled Broadcasting”
Il dynamic querying interagisce con il Query
Routing Protocol (QRP)
Obiettivo:
impedire che siano inviati messaggi di
lookup che non ritornerebbero risultati
21/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Dynamic Querying: search our
leaves
L’ultrapeer manda a tutti i suoi nodi foglia
una query di lookup con TTL=1
Dopo l’invio si attende per 2,4s
I nodi foglia che hanno copia della risorsa
risponderanno alla query
leaf
T
leaf
22/72
TTL
=1
1
L=
T
leaf
1 ultrapeer
=
L
T
T
=1
L
r
TT
e
w
s
An
leaf
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Dynamic Querying: probe query
L’ultrapeer manda a tutti gli ultrapeer ad esso
collegati una query di lookup con TTL=1
Gli Ultrapeer che hanno copia della risorsa
risponderanno alla query
Gli ulrapeer inoltrano la richiesta ai loro nodi leaf
Questa query serve a stimare la popolarità della
risorsa
Se si ottengono 150 risposte positive in tutto
l’algoritmo finisce
leaf
TTL=1
ultrapeer
Answer
leaf
23/72
=1
L
T
T
ultrapeer
Algoritmi per protocolli peer-to-peer - Torrero
TTL
=1
1 ultrapeer
=
L
T
T
1
=
L
T
r
T
e
w
s
n
A
ultrapeer
3/11/2006
Dynamic Querying: controlled
broadcasting
Ogni 2.4s ultrapeer manda una query a uno solo
degli ultrapeer connessi
Se si ottengono 150 risposte positive l’algoritmo
finisce
Se trascorrono più di 200s dall’inizio della ricerca
l’algoritmo è interrotto
E’ una ricerca in profondità:
La probe query stimava la popolarità della risorsa
presso i soli ultrapeer vicini
Il controlled broadcasting effettua una ricerca
approfondita partendo da uno solo degli ultrapeer
vicini
A seconda del valore del TTL si parla di:
24/72
TTL=2 oppure TTL=3 a seconda del numero di risposte
ottenute nella fase precedente
Ricerca TTL2
Ricerca TTL3
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Ricerca TTL2 e ricerca TTL3
Ultrapeer A
TTL=2
Ultrapeer B
TTL=1
Leaf 1
Ultrapeer C
Leaf 2
A inizia la ricerca: manda query con TTL=2 SOLO a B
B decrementa il TTL=> TTL=1
C decrementa il TTL => TTL=0
25/72
TTL<>0 => inoltra la query a TUTTI gli ultrapeer ad esso
collegati (in figura, C è il solo connesso)
TTL=0 => inoltra la query a TUTTI i leaf ad esso collegati
La TTL3 funziona nello stesso modo (TTL=3)
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Gnutella: Query Routing Protocol
Nel Dynamic Querying gli ultrapeer
inoltravano le query ai nodi leaf collegati
Se
il nodo leaf non mantiene risorse, è inutile
propagare la query
Se l’utente del nodo leaf non vuole rispondere
alle query, è inutile propagargli la query
Il QRP a questo scopo permette al nodo leaf
di mandare all’ultrapeer una descrizione
delle risorse gestite mentre si connette
Le
informazioni sono contenute nella QRP table
leaf
GNUTELLA connect/0.6
X-Ultrapeer=false
QRP table
26/72
Algoritmi per protocolli peer-to-peer - Torrero
ultrapeer
GNUTELLA/0.6 200 OK
3/11/2006
Kazaa: introduzione
27/72
Kazaa è stato scritto da Niklas Zennstrom e
Janus Friis nel 2001
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kazaa: overlay gerarchico
TCP
P
TC
SN
ON
TC
P
TC
P
SN
TCP
ON
SN
28/72
SN
Basata sul protocollo Fast Track
Rete gerarchica a 2 livelli
TCP
SuperNodi (SN)
Nodi Ordinari (ON)
Le connessioni tra SN e ON e tra SN e SN sono su
TCP
Si utilizza HTTP per il download dei dati
Tutto il traffico di segnalazione (connessione +
lookup) è criptato
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kazaa: ingresso nella rete
1.
Ogni nodo mantiene una cache di SN (SN cache list)
Esistono default server se la cache è vuota
All’inizio un ON prova tutti i SN nella cache con pacchetti
UDP
ON
2.
SN
UDP prob
e
SN
L’ON inizia connessioni TCP simultanee con più SN
ON
3.
be
UDP pro
ect
TCP conn
SN
TCP conn
ec
SN
t
L’ON seleziona un SN e si disconnette dagli altri
ON
ct
disocnne
SN
SN
29/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kazaa: metadata
Quindi manda in upload al suo SN metadati circa i
file che contiene
Manda IP della macchina ON, nomi dei file, metadati
sui file stessi
I metadati per un file includono:
nome file
dimensione
contenthash che identifica la risorsa (file)
ON
30/72
Metadata
SN
E’ come se ogni SN fosse un piccolo server Napster
Ogni SN tiene informazioni solo sui suoi ON (non su
quelli dei SN vicini)
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kazaa: neighbor selection
Ogni SN manda ai suoi ON una lista con 200
altri SN alla connessione
ON
Lista SN alternativi
SN
Queste informazioni sono usate per
popolare la SN cache List
I
SN nella cache list sono quasi tutti nodi “vicini”
al nodo
Vicinanza valutata sulla base dell’RTT (il 60% dei
nodi in cache list RTT<50ms)
31/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kazaa: lookup delle risorse(1/2)
1.
Ricerca di blocchi di metadati che corrispondono
alla parola chiave
‘Gatto’ ?
ON
2.
SN
Query(‘Gatto’)
I SN inoltrano ad altri SN le richieste di lookup
Algoritmo non noto, forse dynamic querying o
random walk:
SN sceglie a caso un vicino e gli passa la richiesta
Migliorabile parallelizzando richieste
Scelgo SN 3
SN
32/72
Query(‘Gatto’)
Algoritmi per protocolli peer-to-peer - Torrero
SN 1
Query(‘Gatto’)
Rispondo alla
query
SN 3
3/11/2006
Kazaa: lookup delle risorse(2/2)
3.
Le risposte contengono i metadati relativi al file includendo le
informazioni sui peer su cui si trovano
‘Gatto_bianco.txt’
‘Gatto_nero.txt’
ON
4.
La connessione per il download è diretta
Per incrementare le prestazioni il download è fatto scaricando in parallelo il
file a frammenti dall’insieme di nodi che lo contengono
ON
Download(chash)
SN
Se il download fallisce si cerca di nuovo il file direttamente con il
contenthash
ON
33/72
SN
ON sceglie un file e fa una richesta di download con il contenthash
del file come parametro (simile a HTTP GET)
5.
Answer
Query(chash)
Algoritmi per protocolli peer-to-peer - Torrero
SN
3/11/2006
Kazaa: download con firewall
Se il peer richiedente è dietro NAT/firewall, inizia lui il
trasfrerimento
ON A
Downolad(chash)
Kazaa peer
Downolad(chash)
Se il peer con il file è dietro NAT/firewall, inizia lui il
trasferimento
1.
2.
3.
4.
ON A chiede di iniziare attraverso il SN
SN risponde con IP e porta del peer con il file
Il peer con il file manda una richiesta a ON A: pin hole sul NAT
ON A inizia il download come al solito
SN
q
e
_r
d
o
la
i nf
no
w
r
o
e
pe
1:D
:
2
3:GIVE
ON A
1:Downolad(chash)
34/72
N
A
T
1:Do
wno
lad
N
A
T
Algoritmi per protocolli peer-to-peer - Torrero
_re
q
3:GIVE
Kazaa peer
2:Downolad(chash)
3/11/2006
Approccio strutturato
Approccio decentralizzato
non strutturato
I peer si organizzano secondo una topologia precisa
Esiste un directory service distribuito
Ricerche efficienti, ma quanto costa mantenere il
directory service?
Programma:
35/72
strutturato
Le infrastrutture DHT
CHORD)
Kademlia (Emule)
Algoritmo di ricerca avanzato: Chord
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Le infrastrutture DHT: introduzione
(1/2)
Le distributed hash table offrono le funzionalità
tradizionali delle tabelle di hash su un insieme di
nodi
Memorizzazione coppia <chiave, valore>
Il nodo che memorizza la coppia <chiave, valore> è
detto nodo responsabile della chiave
Hash table
36/72
Le DHT nelle infrastrutture peer-to-peer sono usate
per realizzare un name service distribuito
Sono completamente decentralizzate
Sono scalabili
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Le infrastrutture DHT: introduzione
(2/2)
La DHT è realizzata su uno spazio delle chiavi
astratto
Le DHT espongono i messaggi put e get
Put(chiave, valore): inserisce la coppia su un nodo
dell’infrastruttura
Il messaggio può essere inviato a qualsiasi nodo della
DHT: il messaggio viene inoltrato fino al nodo
responsabile per la chiave che memorizzerà il valore
Get(chiave): recupera il valore associato alla chiave
37/72
Solitamente chiavi a 160 bit
Lo spazio degli identificatori delle chiavi coincide con
quello dei nodi
Il messaggio può essere inviato a qualsiasi nodo della
DHT: il messaggio viene inoltrato fino al nodo
responsabile per la chiave non viene raggiunto.
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
DHT: caratteristiche
Assegnazione delle chiavi ai nodi con loadbalancing
Le
chiavi sono assegnate a nodi “vicini” alle
chiavi nello spazio degli ID
A prescindere dal nodo che riceve la
richiesta di lookup, viene localizzato sempre
lo stesso nodo
Ogni algoritmo DHT è caratterizzato da una
funzione distanza fra i nodi
Ogni nodo ha una sua routing table
La
routing table è costruita in modo da adattarsi
alle variazaioni della rete (join e leave dei nodi)
38/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
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
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
39/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Consistent hashing in CHORD
(1/2)
Se N è il numero di nodi presenti sulla rete, al variare di N
si desidera che:
La quantità di dati da rimappare nel sistema sia bassa
Si garantisca l’uniformità della distribuzione delle chiavi sui
nodi
Il consistent hashing organizza i nodi in un cerchio modulo
2 m (m = #bit ID)
0
1
6
2
4
40/72
m=3 #bit chiave
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
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Consistent hashing in CHORD
(2/2)
La chiave k è assegnata al primo nodo n il cui
identificatore è uguale o maggiore all’identifcatore di
k nello spazio degli identificatori
La metrica di distanza in CHORD è la differenza
lineare
Si dice n=successor(k)
41/72
n, il nodo responsabile di k è detto successore di k
CHORD espone la chiamata find_successor per
localizzarlo
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
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
1
6
2
Chiave 5
4
42/72
3
CHORD assicura la validità di questi puntatori
Tuttavia questo è un approccio non ottimale
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
CHORD: lookup scalabile (2/5)
Si suppone che il nodo abbia informazioni
su TUTTI gli altri nodi (routing table
completa)
Dove si trova la
chiave 5?
0
6
1
2
Chiave 5
3
4
Impraticabile: richiede N entry nella routing
table!
43/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
CHORD: lookup scalabile (3/5)
Per ottimizzare CHORD mantiene le finger table
i−1
-iesima entry = identità di s = successor(n + 2 )
con 1≤i ≤ m
Al più m nodi, a regime O(log(n)) in finger table
s è detto –iesima finger del nodo n
La entry contiene l’ID del nodo e il suo IP
il primo finger è l’immediato successore del nodo
sull’anello
0
1
m=3 #bit chiave
3
44/72
Algoritmi per protocolli peer-to-peer - Torrero
Finger table(1)
Valore i entry
1
successor(2)=3
2
successor(3)=3
3
successor(5)=0
3/11/2006
CHORD: lookup scalabile (4/5)
finger[i].start = (n + 2 i −1) mod 2 m
La entry –iesima della finger table copre l’intervallo
[finger[i].start, finger[i+1].start)
m=3 #bit chiave
45/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
CHORD: lookup scalabile (5/5)
46/72
Cosa succede se un nodo cerca una chiave k di cui
non è responsabile?
Il nodo cerca nella finger table il nodo j che precede
immediatamente k e gli inoltra una richiesta per
successor(k)
Nodo 3 vuole successor(1)
1 ∈ [7,3) : quindi 3 manda una query al nodo 0 (entry #3
della finger table)
1 ∈ [1,2): il nodo 0 ha le informazioni su 1 e le manda a 3
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
CHORD: lookup scalabile (4/4)
Si dimostra che con buona probabilità il numero di
nodi da contattare per trovare successor(k) è
O(log(n)) (n=num totale nodi)
Dimostrazione:
n
Sia n il nodo che cerca k e p=predecessore (k)
f = -iesima finger
i −1
n +2
f
p
Finger[i].start
2 i −1
d(f,n) ≥ 2i−1, d(p,f) ≤ 2i−1
n +2 ∗ 2 i −1
Finger[i+1].start
2 i −1
=> Al massimo d(p,f) = (1/2)*d(p,n)
=> A ogni passo la distanza da p si dimezza
m
=> la distanza massima è N= 2 in m passi al massimo si arriva
47/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
CHORD: join dei nodi
Per semplificare le operazioni ogni nodo
tiene conto del suo predecessore
Operazioni da svolgere al join di un nodo n:
Inizializzare
predecessore e finger di n
Aggiornare le finger e i predecessori degli altri
nodi per tenere conto di n
Il nodo n deve entrare nelle finger table degli altri
Muovere sul nodo n tutte le chiavi di cui è il
successore
N diventa responsabile solo per parte delle
chiavi contenute nel suo successore
48/72
Basta contattare un solo nodo
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
CHORD: stabilization
Il join (o l’uscita) dei nodi dall’anello rendono
le informazioni nelle finger table non coerenti
Per completare una ricerca è sufficiente che i
nodi conoscano il loro successore
Tuttavia questo non è ottimale
Occorre che le finger table convergano
rapidamente
A questo scopo un nodo n esegue
periodicamente stabilize
Verifica
periodicamente il nodo che lo segue
sull’anello e gli dice che è connesso
49/72
Periodicamente un nodo n aggiorna le sue
finger
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
CHORD: uscita dei nodi
L’uscita dei nodi si potrebbe trattare come
una failure degli stessi e non fare nulla
La stabilization gestirebbe l’uscita
automaticamente: approccio inefficiente
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
50/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
CHORD: ridondanza informazioni
Perché CHORD funzioni occorre che ogni
nodo conosca il suo immediato successore
sull’anello
Per evitare problemi dovuti a failure dei
nodi, ogni nodo mantiene una lista dei nodi
che lo seguono (lista di successori)
Nel caso in cui un nodo non è utilizzabile
attraverso la lista di successori è possibile
individuare percorsi alternativi.
Per tenere conto delle liste di successori
occorre modificare opportunamente le
operazioni svolte durante la stabilizzazione
51/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia
Sistema di lookup che utilizza metriche
basate su XOR
Kademlia utilizza query parallele asincrone
Gli identifcatori delle risorse sono chiavi su
160 bit (SHA-1)
Date due chiavi x e y la loro distanza è
d(x,y)=x xor y
Kademlia è unidirezionale
=
per ogni d e x, c’è un solo y per cui d(x,y)=x xor
y
=> Le ricerche convergono sullo stesso percorso
52/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia: binary tree
Kademlia tratta i nodi come foglie di un albero
binario
53/72
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, recursivamente
Kademlia garantisce che il nodo con prefisso
univoco 000 conosca almeno un nodo in ciascuno
degli altri sottoalberi
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
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
54/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia: k-buckets (1/5)
Per ogni 0 ≤i<160, ogni nodo ha una lista di
<IP,porta,NodeID> per i nodi che distano tra 2^i e
2^(i+1) da se => k-buckets
m=3 #bit chiave
Tabella nodo 0
0
[1,2)
1
[2,4)
2
[4,0)
nodo1
nodo2
nodo3
nodo4
nodo5
K-bucket
K = numero massimo di elementi in un k-bucket:
parametro di sistema fisso (qui k=2)
55/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia: k-buckets (2/5)
56/72
Quando un nodo riceve un quasliasi messaggio, aggiorna il kbucket corrsipondente
Algoritmo (il nodo A riceve un messaggio dal nodo B):
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia: k-buckets (3/5)
Esempio:
Tabella nodo 0
0
[1,2)
1
[2,4)
2
[4,0)
nodo1
nodo2
nodo3
nodo4
nodo5
nodo4
m=3; k=2
1. 6 manda un messaggio a 0, ma il k-bucket è pieno (k=2)
2. 0 interroga 4
3. 4 risponde e viene spostato al fondo (6 è fuori)
57/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia: k-buckets (4/5)
Esempio:
Tabella nodo 0
miss
0
[1,2)
1
[2,4)
2
[4,0)
nodo1
nodo2
nodo3
nodo4
nodo5
nodo6
m=3; k=2
1. 6 manda un messaggio a 0, ma il k-bucket è pieno (k=2)
2. 0 interroga 4
3. 4 non risponde: 6 è messo in fondo al k-bucket
58/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia: k-buckets (5/5)
Tabella nodo 0
Tabella nodo 0
0
[1,2)
1
1
[2,4)
2
3
2
[4,0)
4
5
6
0
000-
1
1
001-
2
3
2
01--
4
5
k-bucket 1
k-bucket 2
k-bucket 0
59/72
Algoritmi per protocolli peer-to-peer - Torrero
6
3/11/2006
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
Le informazioni vengono replicate
STORE(chiave)
FIND_NODE: data una chiave ritorna (IP, porta,
NodeID) per i k nodi più vicini alla chiave.
60/72
<chiave, valore>
I k nodi possono provenire da più k-bucket se il kbucket più vicino non è pieno
FIND_VALUE: variante della precedente per ottenere
un valore data una chiave
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia: node lookup (1/4)
Obiettivo: localizzare il nodo più vicino a
un Node ID A.
Se il nodo 1 vuole contattare il nodo 5:
1
1
6
0
0
1
0
4
1
3
1
0
0
1
2
1
0
0
5
1. Nodo 1 manda FIND_NODE(5) a uno dei nodi nel k-bucket 1--.
(perche il bucket 1– è il più vicino a 5)
(si suppone che 5 non sia nei k-bucket di 1)
61/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia: node lookup (2/4)
1
1
6
0
0
1
5
0
4
1
3
1
0
0
1
2
1
0
0
2. Il nodo 6 ritorna al nodo 1 l’indirizzo del nodo 4
(il più vicino a 5)
(si suppone che 5 non sia nei k-bucket di 6)
3. Il nodo 1 manda una FIND_NODE(5) al nodo 4
62/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia: node lookup (3/4)
1
1
6
0
0
1
5
0
4
1
3
1
0
0
1
2
1
0
0
4. Il nodo 4 risponde infine al nodo 1 dicendogli l’indirizzo del nodo 5
5. Il nodo 1 può contattare il nodo 5
63/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia: node lookup (4/4)
E’ possibile dimostrare che il numero di passi per
localizzare un nodo è logaritmico
Nell’algoritmo reale vengono inviate più richieste in
parallelo
64/72
Si manda un numero di richieste < k
In questo modo si evitano problemi con i timeout dei nodi
offline
Le risposte alle richieste contengono i k nodi più vicini
L’algoritmo recursivo termina quando i k nodi più vicini al
nodo destinazione hanno risposto
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Kademlia: join, leave, refresh
Come fa un nodo a entrare nell’overlay:
Ottiene
in qualche modo dei contatti da un nodo
nell’overlay
Fa un lookup di se stesso
Il costo del join è circa O(log(n))
Un nodo esce dall’overlay:
Nessuna
65/72
operazione da svolgere
Refresh periodico (orario se necessario) del
contenuto dei k-bucket
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
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
Esiste
sempre più di un percorso alternativo
Le ricerche sono parallelizzate
La manutenzione della routing table è più bassa
66/72
E’ possibile dimostrare che il numero di
entry nella routing table di Kademlia è
logaritmico
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
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
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:
67/72
Rilevare la failure
Replicare i dati persi dal peer disconnesso
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
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
porblemi: 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
68/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Limiti delle DHT (3/3)
Tuttavia la distribuzione delle richieste
privilegia i file più replicati
Questo
limita gli svantaggi delle reti non
strutturate
69/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Bittorent (1/2)
La rete Bittorrent si basa su tracker
I Bittorrent indexer localizzano i file
Per condividere un file il client creano un torrent
Spesso integrato con servizio di lookup
Il tracker è un web server che offre supporto per il
download
Il torrent è un metadata che descrive il file
La pubblicazione di un file su Bittorrent richiede:
Creazione di un file “.torrent” che descrive un file
Creare un tracker per quel file sul webserver locale
Creare una copia “seed” per quel download
70/72
La copia seed altro non è che una copia integrale del
file
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Bittorrent(2/2)
I file condivisi sono suddivisi in frammenti
Normalmente
piccoli
Il download avviene in parallelo sui frammenti
Bittorrent si basa sul meccanismo tit-for-tat
Più
si fa scaricare, più si scarica in fretta
Bittorrent trackerless
Ogni
client diventa un un tracker leggero
I client sono organizzati in una DHT
L’algoritmo DHT usato è Kadmelia
Kadmelia permette di memorizzare e localizzare
contatti per interagire con altri peer
71/72
Algoritmi per protocolli peer-to-peer - Torrero
3/11/2006
Conclusioni
Le reti peer-to-peer permettono un miglior
sfruttamento delle risorse delle reti
Partite da un approccio parzialmente
client/server si sono evolute verso un peerto-peer puro
Le DHT hanno migliorato le caratteristiche
di scalabiltà delle reti gerarchiche
Tuttavia vanno incontro a un certo overhead
di gestione
Attraverso successivi sviluppi le DHT
stanno riducendo l’overhead, fornendo una
sempre più una alternativa concreta alle reti
non strutturate
72/72
Algoritmi per protocolli peer-to-peer - Torrero