Sistemi peer-to-peer Sistemi peer-to-peer

Transcript

Università degli Studi di Roma “Tor Vergata”
Facoltà di Ingegneria
Sistemi peer-to-peer
Corso di Sistemi Distribuiti
Valeria Cardellini
Anno accademico 2009/10
Sistemi peer-to-peer (P2P)
• Giunti agli oneri della cronaca alla fine degli anni ‘90
– Il famoso caso Napster (sistema di file sharing per file MP3)
• Molto popolari
– Parte consistente del traffico Internet: più del 30% è riconducibile
ad applicazioni di tipo P2P
– Trend crescente
• Qualche anno fa si diceva Internet = Web
• Alcuni pregiudizi sul P2P
– P2P = file sharing
• Molti sistemi per il file sharing si basano su un approccio P2P
– P2P = illegalità
• Una percentuale massiccia di file scambiati è coperta da copyright
SD - Valeria Cardellini, A.A. 2009/10
2
Obiettivi e problemi dei sistemi P2P
• Obiettivi
–
–
–
–
–
–
Condividere/ridurre i costi usando risorse non utilizzate
Migliorare la scalabilità
Aumentare la persistenza e la disponibilità delle risorse
Consentire l’aggregazione di risorse e l’interoperabilità
Aumentare l’autonomia
Aumentare l’anonimato/privacy, nascondendo le operazioni
svolte dagli utenti
– Consentire dinamismo e comunicazioni ad-hoc
• Problemi
– Sicurezza: garantire integrità e autenticità delle risorse
– Disuguaglianza tra i nodi
– Elevato tasso con cui i nodi entrano/escono dal sistema P2P
• Può portare ad una instabilità del sistema che ne influenza
negativamente le prestazioni
3
Argomenti trattati
• Già trattati argomenti riguardanti i sistemi P2P, in
particolare il routing
– Overlay routing, routing in reti strutturate e non
– Vedi “Architetture dei SD”
• Quali altri argomenti tratteremo?
– Architetture dei sistemi P2P
– Approfondimento su routing basato su DHT
– Case study: Gnutella, BitTorrent, Skype
4
Architetture per sistemi P2P non strutturati
• Classificazione delle architetture in base al livello di
distribuzione dell’indice risorse-peer
– Architettura decentralizzata pura
• Tutti i nodi sono peer, nessun coordinatore centralizzato
• Ogni peer può funzionare come router, client, o server
• La rimozione di un peer non riduce le funzionalità del sistema
– Architettura centralizzata
• Unico server centralizzato che possiede l’indice e fornisce il servizio
di ricerca delle risorse
– Architettura ibrida
• Alcuni nodi (super-peer) facilitano l’interconnessione tra i peer
– Indice locale centralizzato per risorse dei peer locali
• Prima comunicazione con un super-peer (a), poi con il peer (b)
Decentralizzata pura
Ibrida
5
Architetture per sistemi P2P non strutturati (2)
• Sistemi non strutturati
centralizzati: directory
centralizzata
– Es.: Napster
• Sistemi non strutturati
decentralizzati puri: flooding (o
gossiping)
– Già esaminati
– Problema del bootstrap
– Es.: Gnutella 0.4, Freenet
• Sistemi non strutturati ibridi:
directory semi-centralizzate e
flooding limitato
– Es.: Gnutella 2, KaZaa, Skype
6
Sistemi centralizzati
• Un nodo centralizzato (directory server) possiede il
mapping risorse-peer (index), fornendo un servizio di
discovery dei peer e di ricerca delle risorse
• Limiti
– Gestione costosa della directory centralizzata
– Collo di bottiglia costituito dal nodo centrale (scalabilità
limitata)
– Single point of failure (motivi tecnici e legali, es. Napster)
peers
Napster server
Index
1. File location
request
2. List of peers
offering the file
5. Index update
Napster server
Index
3. File request
4. File delivered
7
Bootstrap nei sistemi decentralizzati puri
• Per accedere alla rete P2P occorre conoscere
l’indirizzo di almeno un nodo (problema del
bootstrap)
• Quali sono gli approcci possibili per il bootstrap nei
sistemi P2P con architettura decentralizzata pura?
• Presenza di un bootstrap server
– Web server che memorizza una lista di peer attivi (con alta
probabilità presenti nella rete P2P)
• Tramite peer cache
– Ogni peer mantiene in una propria cache una lista di peer
contattati nelle sessioni precedenti
• Tramite well-known host
– Non esiste alcuna entità che registra i peer attivi
8
Sistemi ibridi
• Non tutti i peer sono uguali
– I nodi meglio connessi e con buona capacità computazionale
possono avere funzioni speciali (detti supernodi o super-peer o
ultrapeer); gli altri nodi sono detti leaf peer
– Super-peer identificati dinamicamente tramite un algoritmo di
elezione
• Organizzazione two-tier dei nodi
– Super-peer agiscono da rappresentanti dei leaf peer
• I super-peer hanno funzione di directory semicentralizzata
– I supernodi indicizzano le risorse disponibili nei peer che
gestiscono
• Il flooding riguarda solo i super-peer
• Rispetto ai sistemi decentralizzati puri
– Si riduce il tempo di discovery
– Si sfrutta l’eterogeneità hw e sw dei nodi presenti in una rete
P2P
9
Query di una risorsa con super-peer
A!
A!
A?
A?
A!
A?
A?
A?
A?
10
Routing in sistemi strutturati basati su DHT
• Già esaminato il routing in Chord
• Analizziamo il routing in altri due sistemi P2P
strutturati
– Pastry
– CAN
11
Pastry
• Fornisce un substrato per applicazioni P2P
– Alcune applicazioni: Scribe (multicast), SQUIRREL (caching
coooperativo), PAST (storage)
• Sviluppato da Microsofrt research e Rice Univ.
http://www.freepastry.org/
• Routing basato su algoritmo di Plaxton (anche detto
Plaxton routing)
– La struttura mesh di Plaxton contiene puntatori ai nodi il cui
ID corrisponde agli elementi di una struttura ad albero di
prefissi di ID
– In realtà, Pastry usa tecniche più complesse: un set di leaf
node (i nodi più vicini sullo spazio degli ID)
• Anche in Tapestry e Kademlia (altri sistemi P2P
basati su DHT) il routing è basato su Plaxton
12
Pastry (2)
• Ogni peer e ogni risorsa sono mappati su uno spazio
hash circolare
– Come in Chord
• Chiavi rappresentate con d simboli di b bit
• Ogni nodo possiede una tabella di routing
• Ad ogni passo del routing, si inoltra la ricerca al nodo
con ID più vicino all’ID del nodo di destinazione
– Longest prefix matching
– Es: ***8 ! **98 ! *598 ! 4598
13
Plaxton routing
• Esempio: lavoriamo in base 4 con 4 cifre (b=2, d=4
! chiavi di 8 bit)
– Di solito chiavi molto più lunghe (128 bit)
• Regole di composizione della tabella di routing
– Gli ID dei nodi sulla riga
n-esima condividono le
stesse prime n cifre con
l’ID del nodo corrente
– La (n+1)-esima cifra degli
ID sulla riga n-esima è il
numero di colonna
• Per ogni entry, possono
esserci più nodi
candidati: si sceglie il
più vicino in base a
metriche di prossimità
(ad es. RTT)
Nodo 1220
1
2
0
0
1
2
3
3
(0)212
-
(2)311
(3)121
1(0)31
1(1)23
-
1(3)12
12(0)0
12(1)1
-
12(3)1
-
122(1)
122(2)
122(3)
14
Plaxton routing (2)
• Query inoltrata in base a meccanismo di longest
prefix matching
– Al nodo che condivide col nodo di destinazione almeno una
cifra in più del nodo corrente
– Se non esiste, al nodo numericamente più vicino
Nodo 1220
Routing 0321
(0)212
-
(2)311
(3)121
Routing 1106
Routing 1201
1(0)31
1(1)23
-
1(3)12
12(0)0
12(1)1
-
12(3)1
-
122(1)
122(2)
122(3)
Routing 1221
15
Esempio di routing in Pastry
Consideriamo un namespace di 218, 005712 ! 627510
005712
0 1
2
3 4
5
6 7
340880
0 1
2
3 4
5
6 7
943210
0 1
2
3 4
5
6 7
005712
340880
943210
834510
834510
0 1
2
3 4
5
6 7
387510
0 1
2
3 4
5
6 7
727510
0 1
2
3 4
5
6 7
627510
0 1
2
3 4
5
6 7
387510
727510
Quanti hop? Meno
di "log2bN#
627510
16
CAN
•
•
•
•
•
Content Addressable Network
Spazio hash: peer e risorse sono disposti un uno
spazio d-dimensionale suddiviso in zone
Ogni nodo è responsabile di una zona
Ogni risorsa è individuata da d coordinate (usate d
funzioni hash)
Es. bidimensionale (d=2)
17
Routing in CAN
• Ogni nodo conosce i nodi topologicamente adiacenti
(nodi con cui ha un lato/iperpiano in comune)
• Per ottenere la risorsa si deve raggiungere la relativa
zona
• Messaggio inoltrato al vicino che ha coordinate più
“vicine” alla destinazione
• Costo del lookup O(N1/d)
• Resistente ai guasti
18
Case study: Gnutella 0.4
• Gnutella versione 0.4: implementa un’architettura
decentralizzata pura
• Bootstrap e discovery di peer
– Boostrap tramite boostrap server e peer cache
– Ottenuta la lista di peer della rete Gnutella, il peer prova a
connettersi con alcuni dei peer noti
– La rete viene esplorata mediante l’invio di messaggi di
ping/pong
– A seconda della velocità di connessione, il peer prova a
mantenere da 3 a 8 connessioni
– Se una connessione viene persa, il peer cerca di connettersi
ad un altro peer della lista (continuamente aggiornata)
• Ricerca di risorse
– Per la ricerca, Gnutella utilizza un flooding con esplorazione
breadth-first (BFS)
– Invio di un messaggio di query ai peer vicini, che a loro volta
possono inoltrare la query mediante flooding, limitato da TTL
19
Gnutella: connessione
Bootstrap server
n1
n2
n3
•
Un peer può rifiutare una richiesta di connessione, ad esempio
perché ha raggiunto un numero massimo di connessioni ammesse
20
Gnutella: comunicazione fra peer
• I peer comunicano fra loro con messaggi (detti
descriptor); 5 tipi di messaggi nel protocollo Gnutella:
• Ping
– Messaggio per il discovery dei peer vicini nella rete P2P
• Pong
– Messaggio di risposta a un Ping: un peer che riceve un Ping
risponde con uno o più Pong, includendo il suo indirizzo
• Query
– Messaggio di richiesta per localizzare una risorsa
• QueryHit
– Messaggio di risposta a una query: contiene le informazioni
per reperire la risorsa
• Push
– Messaggio per il download da peer dietro un firewall tramite il
protocollo HTTP
21
Gnutella: struttura dei messaggi
Descriptor ID
16 byte
Payload
descriptor
TTL
Hops
Payload length
1 byte
1 byte
1 byte
4 byte
• Descriptor ID: identificatore univoco del messaggio
(GUID) all’interno della rete
– Usato per associare le risposte alle richieste e per evitare di
propagare le stesse richieste più di una volta
• Payload descriptor: identifica il tipo di messaggio
• TTL: numero di hop che il messaggio può attraversare
prima di essere rimosso dalla rete
– Ad ogni hop TTL è decrementato
• Hops: numero di hop che il messaggio ha attraversato
– Ad ogni hop Hops è incrementato
• All’i-esimo passo: TTL(i) = TTL(0) - Hops(i)
• Payload length: dimensione dei dati associati al
messaggio
22
Gnutella: Ping e Pong
• Ogni peer invia periodicamente il messaggio di
Ping per sondare la rete alla ricerca di altri peer
– Un peer che riceve un Ping risponde inviando al mittente
un Pong
• Il messaggio Pong contiene: l’IP e la porta su cui il peer
accetta connessioni, il numero di file condivisi e il numero
di Kb totali condivisi
– Possono essere inviati più messaggi di pong per
comunicare il contenuto della propria peer cache
– ll messaggio di Ping viene
inoltrato ai vicini fino a che il
TTL non si annulla
23
Gnutella: Query e QueryHit
• Query specifica il criterio di ricerca e la velocità di
trasferimento minima richiesta ai peer
Number of hits
1 byte
Port
2 byte
IP
Speed
Result set
server ID
4 byte
4 byte
N byte
16 byte
• QueryHit riguarda tutti i risultati
trovati su un dato peer che
soddisfano il criterio di ricerca
– Port: porta su cui il peer accetta
connessioni in entrata
– Result set: contiene gli identificatori
delle risorse che soddisfano la query
– Servent ID: identifica univocamente il
peer nella rete
24
Gnutella: download di un file
• Il peer richiede direttamente il trasferimento di un file
ad un peer che ha risposto alla query
– Il protocollo usato per il trasferimento è HTTP
GET /get/<file index>/<file name>/
HTTP/1.0
HTTP
200 OK
Connection: keep-alive
Server: Gnutella
Range: bytes=0Content-type: application/binary
User-Agent: Gnutella
Content-length: 200346
... data...
25
Case study: BitTorrent
• E’ il più popolare protocollo P2P per la distribuzione
di contenuti
– Oltre 20% dell’intero traffico su Internet
• Si basa su un’architettura centralizzata
– Sistema per la distribuzione di file (no sistema di routing): si
concentra sulle problematiche di download
• Idea di base: dividere un file in parti di dimensione
fissa e far ridistribuire ad ogni peer i dati ricevuti,
fornendoli a nuovi destinatari; in questo modo:
– Si riduce il carico di ogni sorgente
– Si riduce la dipendenza dal distributore originale
– Si fornisce ridondanza
• Sfrutta potenzialità di download paralleli
26
BitTorrent: struttura della rete
Seeder
Tracker
statistics
Peer list
Leecher
• Approccio tit-for-tat o altruismo reciproco (teoria dei
giochi)
– Stimola la collaborazione fra i peer
– I peer cooperanti ricevono e inviano parti del file; se un peer
smette di fare l’upload, gli altri peer smettono di trasferire
verso di esso
– Limita il “free riding”
• Free rider: esegue solo download, senza contribuire alla rete
27
BitTorrent: seeder e leecher
• Seeder: peer che possiede una copia completa del file
– All’inizio deve esistere almeno un seeder (da cui è scaricato
tutto il file almeno una volta)
– Il numero dei seeder aumenta nel tempo e poi decade (i peer
che hanno completato il download si disconnettono dopo un
po’)
• Leecher: peer per cui il download è ancora incompleto
– Il numero di leecher cresce velocemente quando il file è reso
disponibile
– Raggiunge un massimo e poi decade
– Il picco precede quello dei
download completati
28
BitTorrent: pubblicazione
• Per condividere un file, un peer crea un file .torrent,
che contiene metadati sul file condiviso (dimensione,
nome, hash) ed informazioni sul tracker
– Tracker: il nodo che coordina la distribuzione del file
• Per scaricare un file, un peer
– Ottiene un file .torrent per quel file
– Si connette al tracker individuato in .torrent, che indicherà da
quali peer scaricare le varie parti del file
– Si connette ai peer individuati per scaricare le varie parti
• Un gruppo di peer interconnessi per condividere un
“torrente” viene detto swarm
– Se lo swarm contiene solo il seeder iniziale, il peer si
connette direttamente al seeder
– Mano a mano che i peer entrano nello swarm, iniziano a
negoziare tra loro pezzi del file (anziché scaricarli dal seeder)
29
BitTorrent: scelta della lista dei peer
• Il trasferimento è completamente gestito fra i peer
• Il tracker è l’unico punto di coordinamento fra i peer
• Quando un peer si connette, il tracker invia una lista
casuale di peer a cui connettersi
– Nonostante la semplicità della costruzione, il grafo random
risultante ha buone caratteristiche di robustezza
• Il grafo rimane connesso anche se alcuni peer si disconnettono
• Nel tempo tutte le parti del file si distribuiscono con gli scambi fra
nodi vicini
• Ogni parte del file deve poter raggiungere un peer attraverso i
cammini nel grafo
30
BitTorrent: trasferimento del file
• File divisi in parti di dimensione fissa (ad es. 256 KB)
• Ogni peer notifica ai vicini quali parti possiede
– Correttezza delle singole parti verificata tramite hash (SHA1)
contenuto nel file .torrent
• Più richieste contemporanee per nascondere la
latenza dei trasferimenti
– Le parti sono divise in blocchi (tipicamente 16 KB)
– Si richiedono più blocchi in pipeline (tipicamente 5)
– Quando un blocco termina, si invia una nuova richiesta
31
BitTorrent: strategie di scelta delle parti
• Occorre usare una strategia ottimale per scegliere le
parti da trasferire
– Evitare di (a) possedere già tutte le parti che sono offerte dai
peer vicini; (b) non avere parti da trasferire verso i peer con cui
si vuole collaborare
• Tecniche usate:
– Una volta richiesto un blocco di una parte, le richieste
successive mirano a terminare la stessa parte (priorità stretta)
– Scaricare le prime parti selezionandole in modo casuale per
aumentare la possibilità di trading con gli altri peer
– Scaricare le rimanenti parti selezionandole in base alla
strategia rarest first
• Prima la parte più rara (disponibile nel minor numero di peer vicini)
– Quando il download sta per terminare, i blocchi sono richiesti a
tutti i peer (modalità end game)
• Si mandano delle cancellazioni delle richieste quando arriva un
blocco
• Modalità attiva per un periodo breve
32
BitTorrent: allocazione delle risorse
• No allocazione centralizzata delle risorse
– I peer applicano una politica per massimizzare il loro tasso di
download
• I peer decidono gli upload utilizzando una politica titfor-tat
– I peer possono rifiutare di concedere l’upload
temporaneamente (choking)
– Obiettivo: utilizzare in modo uniforme tutte le risorse ed
evitare la presenza di peer solo in download e non in upload
• Ottimizzazione globale perseguita cercando di
ottimizzare gli interscambi localmente fra coppie di
peer
– Si fornisce banda in upload verso i peer che a loro volta
forniscono accesso in upload (si ottengono connessioni attive
bidirezionali)
– Sulle connessioni inattive si prova…
33
BitTorrent: choking
• Un peer permette l’upload a un numero fisso di altri
peer (4 per default)
– Come scegliere quali peer abilitare?
• Decisione presa sulla base del tasso di download (misurato con
una media su 20 sec)
• Lista dei peer abilitati ricalcolata ogni 10 sec
• Per evitare di trascurare canali promettenti si attua l’abilitazione
ottimistica di un solo peer, indipendentemente dal suo tasso di
download
• La scelta per l’abilitazione ottimistica viene ruotata ogni 30 sec
per dare il tempo di effettuare una misura attendibile della
reciprocità
– In questo modo, il controllo di congestione del TCP satura la
capacità di upload
34
BitTorrent: anti-snubbing
• Può accadere che un peer sia disabilitato dal
download da tutti i peer
– In questo caso, avrà un basso tasso di download fino a che
l’abilitazione ottimistica non trova peer migliori
– Quando per più di 1 min un dato peer non riceve parti da un
altro peer, si assume che è stato escluso (snubbed) e il peer
a sua volta smette di consentire l’upload all’altro peer a
meno di un’abilitazione ottimistica
– Questo provoca più abilitazioni ottimistiche concorrenti
(invece di una sola), rendendo possibile una nuova
selezione dei peer più collaborativi
35
BitTorrent: svantaggi
• Poco adatto per file di piccole dimensioni
• Tracker: limita la scalabilità ed è un single point of
failure
– Decentralizzazione basata su DHT
36
Case study: Skype
• Telefonia IP basata su
sistema P2P
• Architettura P2P ibrida a
due livelli (peer e
ultrapeer), come KaZaa
– Ultrapeer usati
principalmente per
instradare il traffico tra
end-host dietro NAT
– In più, login server per:
• Autenticare gli utenti
• Garantire che i nomi siano
unici in tutta la rete
37

Sistemi peer-to-peer Sistemi peer-to-peer

Transcript

Documenti analoghi

SCHEDA_ programmazione peer to peer

ALLEGATO 3_ scheda programmazione peer to peer

attività peer to peer

Motori di ricerca e P2P

La metodologia della Peer Review tra autovalutazione ed etero

PeerGuardian, valido firewall opensource

CONFIGURAZIONE PEER TO PEER

circolare n - Liceo "Camillo Golgi"