Sistemi non strutturati - the Netgroup at Politecnico di Torino

Livio Torrero - Politecnico di Torino
Algoritmi per protocolli peer-to-peer
Reti non strutturate: casi di studio
Livio.torrero@polito ([email protected])
09/2009
Livio Torrero - Politecnico di Torino
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
2
Livio Torrero - Politecnico di Torino
Funzionamento di Napster
•  Quando un nodo entra nell’infrastruttura si registra
presso il server
–  Upload della lista delle risorse gestite
Peer
Server centrale
Upload
•  Quando un nodo cerca una risorsa fa un lookup sul
server centralizzato
Peer
query
Server centrale
answer
•  In base ai risultati ottenuti il peer si connette a un
altro peer per scaricare la risorsa
Peer
Downloa
d
Peer
Server centrale
3
Livio Torrero - Politecnico di Torino
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 reverse-engineering sono
stati sviluppati numerosi cloni open-source
–  Limewire è software open-source che supporta la rete Gnutella
4
Livio Torrero - Politecnico di Torino
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
5
Livio Torrero - Politecnico di Torino
Gnutella(limewire): rete gerarchica (1/2)
leaf
leaf
ultrapeer
ultrapeer
leaf
ultrapeer
leaf
leaf
ultrapeer
leaf
leaf
•  Ultrapeer
–  Fa da proxy per i nodi leaf
•  Sono loro ad effettuare le ricerche
•  Impediscono che i nodi leaf siano investiti dal traffico ad
alta banda che investe gli ultrapeer
–  Un nodo ultrapeer deve avere una connessione
Internet veloce non bloccata da firewall
•  Deve accettare connessioni TCP da nodi esterni
•  Deve essere possibile mandare pacchetti UDP entranti
•  limewire => upload 10kB/s, download 20kB/s
6
Livio Torrero - Politecnico di Torino
Gnutella(limewire): rete gerarchica (2/2)
leaf
leaf
ultrapeer
ultrapeer
leaf
ultrapeer
leaf
leaf
ultrapeer
leaf
leaf
•  Nodi leaf
–  Es: nodi con connessioni dialup
–  Sono fuori dall’overlay (si connettono agli ultrapeer come client)
–  Non accettano connessioni Gnutella
–  Cercano un ultrapeer a cui collegarsi il prima possibile
•  Dipendono dall’ultrapeer
–  Se un nodo leaf vuole diventare ultrapeer, prima si disconnette
dalla rete per ripresentarsi tentando di diventare ultrapeer
–  Un nodo leaf dovrebbe restare leaf per almeno un’ora
7
Livio Torrero - Politecnico di Torino
Perché una rete a 2 livelli?
•  La divisione tra ultrapeer e nodi normali permette
solo ai nodi “migliori” entrare nell’overlay
–  Gli host lenti rallenterebbero le prestazioni dell’intero
sistema se posti nell’overlay
–  L’overlay diventa più piccolo ma più funzionale
–  Dal punto di vista dei nodi leaf gli ultra-peer sono dei
server
8
Livio Torrero - Politecnico di Torino
Gnutella: overlay discovery
•  Un nodo per accedere all’overlay Gnutella deve
conoscere almeno un ultrapeer
–  Le modalità con cui questo avviene non sono oggetto di
Gnutella
–  Cache, well known nodes…
•  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)
–  Solo gli ultrapeer mandano i pong
•  Quando un ultrapeer riceve dei messaggi pong li mette
nella sua pong cache
–  Solo gli ultrapeer hanno la pong cache
•  Quando un ultrapeer riceve un messaggio ping risponde
con tutti i pong nella sua cache
9
Livio Torrero - Politecnico di Torino
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
•  Handshake a 3 vie:
Host che si
connette
CONNECT
Host che riceve
la connessione
OK
OK
10
Livio Torrero - Politecnico di Torino
Esempi di handshake Gnutella(1/3)
• 
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
GNUTELLA connect/0.6
X-Ultrapeer=false
NAT
leaf
217.254.98
ultrapeer
.153
GNUTELLA/0.6 200 OK
Listen-IP:68.37.233.44:9376
Remote-IP: 217.254.98.153
11
Livio Torrero - Politecnico di Torino
Esempi di handashake Gnutella (2/3)
• 
Un ultrapeer si connette a un ultrapeer
ultrapeer
ultrapeer
GNUTELLA connect/0.6
X-Ultrapeer=true
• 
GNUTELLA/0.6 200 OK
Un nodo si connette a un ultrapeer che rifiuta la connessione
– 
L’ultrapeer deve fornire peer alernativi
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…
12
Livio Torrero - Politecnico di Torino
Esempi di handshake Gnutella(3/3)
• 
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…
13
Livio Torrero - Politecnico di Torino
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
leaf
1h
ultrapeer
ultrapeer
ultrapeer
ultrapeer
–  Poi può tentare di connettersi a un ultrapeer come ultrapeer
ultrapeer?
ultrapeer connect
ultrapeer
ultrapeer
ultrapeer
ultrapeer
–  Se l’ultrapeer lo rifiuta, torna leaf per un’altra ora
ultrapeer?
Refuse connection
ultrapeer
ultrapeer
Leaf for 1h
leaf (!)
leaf connect
ultrapeer
ultrapeer
ultrapeer
ultrapeer
ultrapeer
ultrapeer
14
Livio Torrero - Politecnico di Torino
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
–  Creerà fino a 3 connessioni verso ultrapeer diversi
•  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
–  Un ultrapeer non permette a più di 30 nodi foglia di
connettersi a lui
15
Livio Torrero - Politecnico di Torino
Lookup in Gnutella: introduzione
•  L’algoritmo di lookup è il dynamic querying
–  Obiettivo: localizzare una risorsa con il minor numero di
messaggi possibile
•  Avvio mandando pochi messaggi
•  Intensifica alle fine
•  Se una risorsa è popolare la trovo subito
–  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
16
Livio Torrero - Politecnico di Torino
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
leaf
1
TTL=
ultrapeer
leaf
leaf
17
Livio Torrero - Politecnico di Torino
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
–  Reimpostano TTL=1
•  Questa query serve a stimare la popolarità della risorsa
•  Se si ottengono 150 risposte positive in tutto l’algoritmo finisce
leaf
TTL=1
Answer
ultrapeer
ultrapeer
1
TTL=
ultrapeer
leaf
ultrapeer
18
Livio Torrero - Politecnico di Torino
Dynamic Querying: controlled
broadcasting
•  Ogni 2.4s ultrapeer manda una query a uno solo degli
ultrapeer connessi
–  TTL=2 oppure TTL=3 a seconda del numero di risposte
ottenute nella fase precedente
•  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:
–  Ricerca TTL2
–  Ricerca TTL3
19
Livio Torrero - Politecnico di Torino
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
–  TTL<>0 => inoltra la query a TUTTI gli ultrapeer ad
esso collegati (in figura, C è il solo connesso)
•  C decrementa il TTL => TTL=0
–  TTL=0 => inoltra la query a TUTTI i leaf ad esso
collegati
•  La TTL3 funziona nello stesso modo (TTL=3)
–  la ricerca coinvolge un numero elevato di ultrapeer
–  Limewire non usa MAI TTL>3
20
Livio Torrero - Politecnico di Torino
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
–  Le informazioni sono contenute nella QRP table
–  Inviata dopo la connessione
–  Appositi messaggi permettono l’aggiornamento delle
informazioni della QRP table
21