Sistemi peer-to-peer (P2P)

Transcript

1 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

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 SD - Valeria Cardellini, A.A. 2009/10 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 SD - Valeria Cardellini, A.A. 2009/10 4

3 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 SD - Valeria Cardellini, A.A. 2009/10 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 SD - Valeria Cardellini, A.A. 2009/10 6

4 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 3. File request 4. File delivered Napster serv Index SD - Valeria Cardellini, A.A. 2009/10 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 SD - Valeria Cardellini, A.A. 2009/10 8

5 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 SD - Valeria Cardellini, A.A. 2009/10 9 Query di una risorsa con super-peer A? A! A? A! A! A? A? SD - Valeria Cardellini, A.A. 2009/10 10

6 Routing in sistemi strutturati basati su DHT Già esaminato il routing in Chord Analizziamo il routing in altri due sistemi P2P strutturati Pastry CAN SD - Valeria Cardellini, A.A. 2009/10 11 Pastry Fornisce un substrato per applicazioni P2P Alcune applicazioni: Scribe (multicast), SQUIRREL (caching coooperativo), PAST (storage) Sviluppato da Microsofrt research e Rice Univ. 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 SD - Valeria Cardellini, A.A. 2009/10 12

7 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 SD - Valeria Cardellini, A.A. 2009/10 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 (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) SD - Valeria Cardellini, A.A. 2009/10 14

8 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 (0)31 12(0)0 1(1)23 12(1) (3)12 12(3)1 Routing (1) 122(2) 122(3) SD - Valeria Cardellini, A.A. 2009/10 15 Esempio di routing in Pastry Consideriamo un namespace di 2 18, ! Quanti hop? Meno di "log 2b N# SD - Valeria Cardellini, A.A. 2009/10 16

9 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) SD - Valeria Cardellini, A.A. 2009/10 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(N 1/d ) Resistente ai guasti SD - Valeria Cardellini, A.A. 2009/10 18

10 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 SD - Valeria Cardellini, A.A. 2009/10 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 SD - Valeria Cardellini, A.A. 2009/10 20

11 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 SD - Valeria Cardellini, A.A. 2009/10 21 Gnutella: : struttura dei messaggi Descriptor ID Payload descriptor TTL Hops Payload length 16 byte 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 SD - Valeria Cardellini, A.A. 2009/10 22

12 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 SD - Valeria Cardellini, A.A. 2009/10 23 Gnutella: Query e QueryHit Query specifica il criterio di ricerca e la velocità di trasferimento minima richiesta ai peer Number of hits Port IP Speed Result set 1 byte 2 byte 4 byte 4 byte N byte server ID 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 SD - Valeria Cardellini, A.A. 2009/10 24

13 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 HTTP/ OK Connection: keep-alive Server: Gnutella Range: bytes=0- Content-type: application/binary User-Agent: Gnutella Content-length: data... SD - Valeria Cardellini, A.A. 2009/10 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 SD - Valeria Cardellini, A.A. 2009/10 26

14 BitTorrent: : struttura della rete Seeder Tracker statistics Leecher Peer list 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 SD - Valeria Cardellini, A.A. 2009/10 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 SD - Valeria Cardellini, A.A. 2009/10 28

15 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) SD - Valeria Cardellini, A.A. 2009/10 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 SD - Valeria Cardellini, A.A. 2009/10 30

16 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 SD - Valeria Cardellini, A.A. 2009/10 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 SD - Valeria Cardellini, A.A. 2009/10 32

17 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 SD - Valeria Cardellini, A.A. 2009/10 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 SD - Valeria Cardellini, A.A. 2009/10 34

18 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 SD - Valeria Cardellini, A.A. 2009/10 35 BitTorrent: : svantaggi Poco adatto per file di piccole dimensioni Tracker: limita la scalabilità ed è un single point of failure Decentralizzazione basata su DHT SD - Valeria Cardellini, A.A. 2009/10 36

19 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 SD - Valeria Cardellini, A.A. 2009/10 37