Corso di Applicazioni Telematiche Applicazioni

Corso di Applicazioni Telematiche
Applicazioni peer-to-peer
A.A. 2009-10
Prof. Simon Pietro Romano
Università degli Studi di Napoli Federico II
Facoltà di Ingegneria
Terminologia: “peer-to-peer”
• Sistema distribuito nel quale:
• ogni nodo ha identiche capacità e responsabilità
• tutte le comunicazioni sono potenzialmente simmetriche
• Obiettivi: condividere risorse e servizi
• scambio di informazioni, cicli di CPU, spazio sul disco,
…
• I sistemi P2P possiedono molti aspetti tecnici
interessanti:
• controllo decentralizzato
• adattabilità
• si organizzano e si gestiscono da soli
P2P: classificazione (1/3)
• Le applicazioni P2P sono costituite da tre fasi
principali:
• Boot: permette a un peer di trovare la rete e di
connettersi ad essa
• …nessuno o quasi fa boot P2P
• Lookup:
• permette ad un peer di trovare il gestore/responsabile di
una determinata informazione
• …pochi sono P2P, alcuni usano ‘SuperPeer’
• Scambio di file
• …sono tutti P2P!
P2P: classificazione (2/3)
• P2P pure se:
• le fasi di boot, lookup e scambio di file sono P2P
• P2P se:
• le fasi di lookup e scambio di file sono P2P
• la fase di boot utilizza qualche SERVER
• P2P Ibride se:
• la fase di scambio dei file è P2P
• la fase di boot utilizza qualche SERVER
• nella fase di lookup vengono usati Peer particolari
Hub (Direct Connect)
Supernodo (KaZaA)
MainPeer (EDonkey)
SuperPeer , Ultra Peer(Gnutella2)
NodoRandezVous (JXTA)
Server (WinMX)
P2P: classificazione (3/3)
• Con riferimento all’operazione di
lookup:
• Lookup Centralizzato
• Indice centralizzato
• Lookup Decentralizzato
• Indice completamente distribuito
• Lookup Ibrido
• Più sistemi centralizzati collegati in un
sistema decentralizzato
In tutti e tre questi sistemi il
trasferimento e la memorizzazione
dei file sono P2P
Architetture p2p
• Non esistono server sempre
connessi (always-on server)
• Gli end-system (peer)
comunicano direttamente
peer-peer
• I peer sono connessi ad
intermittenza e cambiano il
proprio IP
• Tre argomenti principali:
• Distribuzione dei file
• Self-scalability
• BitTorrent
• Organizzazione dei peer e
ricerca delle informazioni
• Case Study:
• Skype
• P2p IPTV
File Distribution: Server-Client vs P2P
Quanto tempo serve per distribuire un file da un
server ad N peer (tempo di distribuzione, D)?
us: server upload
bandwidth
Server
us
u1
d1
u2
ui: peer i upload
bandwidth
d2
File, size F (bits)
dN
uN
Network (with
abundant bandwidth)
di: peer i download
bandwidth
N, numero di
peer che
richiedono una
copia di F
File distribution: caso “server-client”
• Il server invia in
sequenza N copie del
file:
Server
F
u1 d1 u2
us
tempo richiesto: NF/us
dN
• Il client i impiega un
tempo pari a F/di per il
download
uN
d2
Rete (con banda
elevata) e appl.
isolate
Approccio client/server
Tempo per distribuire
F bit a N client
= Dcs = max {NF/us, F/min(di) }
i
per N elevato, il termine NF/us è dominante: incremento lineare al crescere di N
File distribution: caso P2P
• Dipende dal numero di peer
coinvolti…
Server
F
• Il server deve inviare almeno
una copia. Tempo richiesto: F/us
us
dN
• Il client i impiega un tempo pari a
F/di per il download (F/dmin)
uN
u1 d1 u2
Rete (con banda
elevata) e appl.
isolate
• NF bit totali devono essere
‘scaricati’: velocità massima di
upload: us + Σui
Approccio p2p
DP2P = max { F/us, F/min(di) , NF/(us + Σui) }
i
d2
Server-client vs P2P: confronto di prestazioni
Ipotesi:
• Tutti i peer hanno lo stesso rate di upload = u
• F/u = 1 ora, us = 10u, dmin ≥ us
Minimum Distribution Time
3.5
P2P
Client-Server
3
2.5
2
1.5
1
0.5
0
0
5
10
15
20
N
25
30
35
File distribution: BitTorrent
• P2P file distribution
tracker: tiene traccia dei peer
che compongono un “torrente”
obtain list
of peers
trading
chunks
peer
torrente: gruppo di
peer che si scambiano
porzioni (chunk) di
un stesso file
BitTorrent (1/3)
Il file è diviso in chunk di 256KB
• Quando un peer si aggiunge ad un “torrente”:
• si registra presso il tracker per avere la lista dei peer e si
connette ad un sottoinsieme di tali peer (“neighbors”)
• non possiede chunk, ma ne accumulerà nel tempo
• Durante il download, il peer esegue
l’upload di chunk verso altri peer
• I peer possono attivarsi e disattivarsi
dinamicamente
• Una volta scaricato l’intero file, il peer
può (egoisticamente) abbandonare, o
(altruisticamente) rimanere nel “torrente”
BitTorrent (2/3)
1) Prelievo di chunk
• Peer differenti
possiedono differenti
sottoinsiemi di chunk del
file
• Periodicamente, un peer
chiede a tutti i ‘neighbor’
la lista dei chunk in loro
possesso
• Tale peer invia richieste
per i propri chunk
mancanti
• tecnica ‘rarest first’
2) Invio di chunk: ‘tit-for-tat’
• L’idea di fondo è quella di dare
priorità a chi fornisce dati al rate
più alto.
• Un peer invia chunk ai 4 neighbor
attualmente più veloci (che gli
inviano chunk al rate più elevato)
• i ‘top 4’ sono ricalcolati ogni
10 secondi
• Ogni 30 secondi: si seleziona in
maniera casuale un altro peer, e
si inizia ad inviargli chunk
• il peer appena scelto può
essere aggiunto ai ‘top 4’
• “optimistically unchoke”
BitTorrent: tit-for-tat
(1) Alice effettua l’ ”unchoke” ottimistico di Bob
(2) Alice diventa uno dei ‘top-four provider’ di Bob, il quale ‘ricambia’
(3) Bob diventa uno dei ‘top-four provider’ di Alice
Free-riding
Con upload rate più elevato,
si trovano partner ‘migliori’ e si
scarica il file più velocemente!
P2P con directory centralizzata:
• Quando un peer si connette alla rete si collega ad un server
centralizzato fornendo:
•
•
Il proprio indirizzo IP
Il nome degli oggetti resi disponibili per la condivisione
• In server in questo modo raccoglie le info sui peer attivi e le aggiorna
dinamicamente
P2P con directory centralizzata:
• Singolo punto di fallimento
• Collo di bottiglia per le prestazioni
• Violazione del diritto di autore
• Il trasferimento dei file è decentralizzato, ma la localizzazione dei contenuti
è pesantemente centralizzata !!!
P2P con directory decentralizzata:
•Architettura completamente distribuita (senza server
centralizzati)
• Si realizza un’architettura di rete sovrapposta (overlay
network, fatta da connessioni TCP in corso)
• L’overlay network ha una struttura paritetica
• Nonostante la rete possa avere centinaia di migliaia di
partecipanti, ogni peer è connesso al max a 10 altri peer nella
overlay.
• Due problematiche:
• come viene costruita e gestita la rete di peer
• come un peer localizza un contenuto
P2P con directory decentralizzata:
• I peer , una volta unitisi alla rete, inviano richieste mediante la tecnica del
flooding (inondazione), query flooding
• Gnutella Query e QueryHit
• Query flooding a raggio limitato
• scope del messaggio (7, ad esempio)
• pro e contro
P2P con directory decentralizzata:
File transfer:
HTTP
Query
QueryHit
Query
QueryHit
P2P con directory decentralizzata:
1. Il peer X deve trovare altri peer già parte dell’overlay
• mantiene una lista di IP o contatta un sito Gnutella
contenente la lista
2. Dopo l’accesso alla lista, X tenta di impostare una
connessione TCP con i peer della lista; quando si connette a Y
si ferma
3. X spedisce a Y un ping Gnutella; Y lo inoltra finchè il contatore
non si azzera
4. Tutti i peer che ricevono un messaggio ping, rispondono con
un pong: esso contiene l’indirizzo di chi ha inviato il pong, il
numero di file in condivisione, la dimensione totale
5. Quando X riceve i messaggi di pong, avendo l’IP, può
impostare una connessione TCP con alcuni di essi…
6. Ci possono essere più fasi di bootstrap in parallelo
P2P con directory decentralizzata:
•
•
•
•
Sfrutta le caratteristiche positive di Napster e Gnutella
Ogni peer è associato ad un group leader (mini hub) che è esso stesso un peer
Un group leader memorizza le informazioni in condivisione dei “figli”
Ogni group leader è in grado di interrogare altri group leader
• query flooding applicato alla rete dei group leader
P2P con directory decentralizzata:
• Fase di bootstrap:
• un peer che si connette deve essere associato ad un group leader o deve
essere designato group leader
• L’overlay è costituita da connessioni TCP tra peer e group leader e tra coppie di
group leader
• Ogni file possiede un identificatore hash e un descrittore
• I peer (client) spediscono le query al proprio group leader
• quest’ultimo risponde per ogni richiesta con:
• l’indirizzo IP del detentore della risorsa, l’hash, e dei metadati associati
alla risorsa.
• il group leader inoltra sia le richieste sia le eventuali risposte da parte di altri
group leader
• Il peer (client) seleziona la risorsa per il download e invia una richiesta HTTP al
detentore della risorsa usando l’hash come identificatore
• Tecniche per migliorare le prestazioni
• Accodamento delle richieste e limitazione del numero degli upload simultanei
•
•
Priorità di incentivo
Downloading parallelo di parti dello stesso file da più utenti
Skype
• Skype è una applicazione P2P VoIP sviluppata da KaZaa nel
2003
• Supporta anche instant messaging e conferencing
• Il protocollo è proprietario
• Skype usa una rete overlay, con tre tipi di host
• Host ordinari:
• Skype users
• Super nodi:
• Skype users con sufficiente CPU, memoria, banda…
• Server di login per l’autenticazione
Skype
• Ciascun client Skype mantiene
una lista di indirizzi IP di super
nodi conosciuti
• Inizialmente questa lista è vuota.
• Un client Skype si connette alla
rete attraverso un super nodo
• I super nodi sono responsabili
della localizzazione degli utenti,
del routing delle chiamate, del
mantenimento delle
informazioni circa gli host
connessi alla rete Skype
Skype
• Connessione ai super nodi:
• Primo login
• Alla prima esecuzione (in seguito all’ l’installazione) un client Skype
comunica con il server Skype (skype.com)
• Durante la comunicazione, la cache dell’host è popolata di 7 indirizzi
IP di super nodi da usare per il bootstrap
• A questo punto l’host può contattare uno di essi per il join
• Selezionato il super nodo per il join, parte la fase di autenticazione con
user name e password con il server Skype
• L’host viene periodicamente aggiornato con indirizzi IP di nuovi super
nodi
• Login successivi
• Per i login successivi un client sceglie uno degli indirizzi dei super nodi
e stabilisce la connessione
p2p IPTV
Keywords:
• Chunk
• Peer-list
• Buffer-map
• Ogni peer è sia un viewer che un
server.
• Alcuni viewer ricevono il flusso
direttamente dalla sorgente originale
(server IPtv); altri lo ricevono
attraverso altri peer.
Scalabilità
• Il lavoro richiesto a un determinato nodo nel sistema
non deve crescere (o, almeno, deve crescere
lentamente) in funzione del numero di nodi nel
sistema
• I protocolli usati da Napster e Gnutella non sono
scalabili
• Per migliorare la scalabilità sono nati (in ambito
accademico) i cosiddetti protocolli P2P di seconda
generazione che supportano DHT – Distributed Hash
Table
• Alcuni esempi di questi protocolli:
• Tapestry, Chord, Can, Viceroy, Koorde, kademlia, kelips, …
Scalabilità e routing delle richieste
• La scalabilità di un protocollo è direttamente legata
all’efficienza dell’algoritmo usato per il routing (lookup)
• Due obiettivi principali:
1. Minimizzare il numero di messaggi necessari per effettuare
il lookup
2. Minimizzare, per ogni nodo, le informazioni relative agli altri
nodi
• Le varie DHT conosciute differiscono proprio per
questi aspetti…
Messaggi necessari per trovare
Anello
una chiave
Chord e altri
n -1
Grafo
Totalmente
connesso
O(log n)
1
1
n è il numero dei peer
O(log n)
n -1
Dimensione tabella di routing
P2P di seconda generazione e DHT
• A ogni file e ad ogni nodo è associata una chiave
• La chiave viene di solito creata facendo l’hash del nome
del file o dell’IP del nodo
• Ogni nodo del sistema è responsabile di un insieme di
file/chiavi e tutti i nodi, nel loro insieme, realizzano una
DHT
• L’unica operazione che un sistema DHT deve fornire è
“lookup(key)”:
• restituisce l’identità del responsabile di una determinata
chiave
DHT: concetti generali
• Astrazione: una struttura dati distribuita che realizza
una tabella hash:
put(id, item);
item = get(id);
• Implementazione: i nodi del sistema costituiscono
una struttura dati distribuita:
anello, albero, ipercubo, rete ‘Butterfly’, ...
Ricerca in una DHT
• Tutti i nodi del sistema condividono una tabella
hash
• conoscono la struttura della tabella…
• ...ma non conoscono il responsabile di
una determinata entry
ID
Nodo x
Nodo y
Nodo z
…
0
1
2
3
4
5
6
…
2m
DHT: Chord
• Le chiavi sono mappate su un array circolare costituito da 2m
identificatori
• Il nodo responsabile di una determinata chiave è il primo
nodo che la succede in senso orario
• Ogni nodo x di Chord mantiene due insiemi di vicini:
Il primo contiene gli m successori del nodo x, più il
predecessore
Il secondo, un insieme di m nodi
costituito dai responsabili delle
m=3
chiavi distanziate
esponenzialmente dal nodo x,
vale a dire l’insieme delle chiavi
che si trovano a distanza 2i da x
dove 0 ≤ i ≤ m-1
Chord: la “finger table”
Successors
ID
Resp.
indice
Nod
o
1
14
8+1=9
14
2
8+2=11
21
14
3
8+4=12
4
8+8=16
5
24
14
32
21
38
8+16=24
6
24
42
8+32=40
42
Predecessor
Nodo 1
m=6
Chord: Join
• Spazio degli identificativi: [0..8]
1. Join del nodo 1
Succ. Table
i id+2i succ
0
0
1
2
1
7
6
2
5
3
4
2
3
5
1
1
1
Chord: Join
2. Join del nodo 2
Succ. Table
i id+2i succ
0
0
1
2
1
7
6
2
3
5
2
1
1
2
Succ. Table
5
3
4
i id+2i succ
0
1
2
3
4
6
1
1
1
Chord: Join
Succ. Table
i id+2i succ
0
1
2
3. Join dei nodi 0 e 6
1
2
4
1
2
0
Succ. Table
i id+2i succ
0
0
1
2
1
7
Succ. Table
2
3
5
2
6
6
i id+2i succ
0
1
2
7
0
2
0
0
2
6
2
Succ. Table
5
3
4
i id+2i succ
0
1
2
3
4
6
6
6
6
Chord: allocazione delle risorse
Succ. Table
i
Nodi:
n1, n2, n0, n6
0
1
2
File:
f7, f1
Items
id+2 succ 7
1
1
2
2
4
0
i
0
Succ. Table
1
7
i
0
1
2
Succ. Table
6
Items
id+2 succ 1
2
2
3
6
5
6
i
2
i id+2i succ
0
1
2
7
0
2
0
0
2
Succ. Table
5
3
4
i id+2i succ
0
1
2
3
4
6
6
6
6
Chord: routing
• Alla ricezione di una query
per il dato con
identificativo id, un nodo:
•
•
Succ. Table
i
0
1
2
Controlla se il dato è
presente presso di sé
In caso di assenza del dato,
esso inoltra la query al nodo
più grande nella sua tabella
dei successori, avente
identificativo di nodo <= di id
Items
id+2 succ 7
1
1
2
2
4
0
i
0
Succ. Table
1
7
i
0
1
2
query(7)
Succ. Table
6
Items
id+2 succ 1
2
2
3
6
5
6
i
2
i id+2i succ
0
1
2
7
0
2
0
0
2
Succ. Table
5
3
4
i id+2i succ
0
1
2
3
4
6
6
6
6
Chord: complessità
• Le informazioni che il nodo deve mantenere
sugli altri nodi sono (m + m + 1) = (2m +1) O(log N)
• Il numero di messaggi necessari per effettuare
il lookup è m O(log N)
• L’algoritmo di routing effettua a ogni step il
passo più grande che riesce a fare
• tale algoritmo, in pratica, simula un “ipercubo”
• esso, inoltre, si comporta molto bene in un sistema
dinamico
P2P e standardizzazione nell’IETF
• p2psip:
• Peer-to-Peer Session Initiation Protocol
• ALTO:
• Application Level Traffic Optimization
• PPSP:
• Peer to Peer Streaming Protocol
p2psip – Peer-to-Peer SIP
p2psip – obiettivi (1/2)
p2psip – obiettivi (2/2)
ALTO – Application Level Traffic Optimization
ALTO – obiettivi e ‘milestone’
PPSP – Peer to Peer Streaming Protocol
PPSP – ipotesi di lavoro e ‘milestone’
Dalla teoria alla pratica: SIPDHT
http://sipdht.sourceforge.net/
• Un progetto gestito dai ricercatori di Tilab Torino
• Attualmente alla versione 2:
• http://sipdht.sourceforge.net/sipdht2
• connessioni tra peer negoziate mediante SIP
• implementazione di una DHT basata su infrastruttura
CAN (Content Addressable Network)
• Ottimizzato per peer nascosti da NAT
Domande?
50