Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria

Transcript

1 Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria 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 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 Valeria Cardellini - SD A.A. 2010/11 2

2 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 Valeria Cardellini - SD A.A. 2010/11 3 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 Valeria Cardellini - SD A.A. 2010/11 4

3 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 Valeria Cardellini - SD A.A. 2010/11 5 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 Valeria Cardellini - SD A.A. 2010/11 6

4 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 Valeria Cardellini - SD A.A. 2010/11 7 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 Valeria Cardellini - SD A.A. 2010/11 8

5 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 Valeria Cardellini - SD A.A. 2010/11 9 A? A! A? A! A! A? A? Valeria Cardellini - SD A.A. 2010/11 10

6 Già esaminato il routing in Chord Analizziamo il routing in altri due sistemi P2P strutturati Pastry CAN Valeria Cardellini - SD A.A. 2010/11 11 Fornisce un substrato per applicazioni P2P Alcune applicazioni: Scribe (multicast), SQUIRREL (caching coooperativo), PAST (storage) Sviluppato da Microsoft Research e Rice University 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 nello spazio degli ID) Anche in Tapestry e Kademlia (altri sistemi P2P basati su DHT) il routing è basato su Plaxton Valeria Cardellini - SD A.A. 2010/11 12

7 Ogni peer e ogni risorsa sono mappati su uno spazio hash circolare Come in Chord Chiavi (ID) 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 Valeria Cardellini - SD A.A. 2010/11 13 Esempio: chiave con b=2 e d=4! chiave 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) Tabella di routing del 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) Valeria Cardellini - SD A.A. 2010/11 14

8 Query inoltrata in base a meccanismo di longest prefix matching Verso il 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 Routing 1106 Routing 1201 Routing 1221 (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) Valeria Cardellini - SD A.A. 2010/11 15 Consideriamo uno spazio degli ID di 2 18, ! Quanti hop? Meno di "log 2b N# Valeria Cardellini - SD A.A. 2010/11 16

9 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) Valeria Cardellini - SD A.A. 2010/11 17 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 le coordinate più vicine alla destinazione Costo del lookup O(N 1/d ) Resistente ai guasti Valeria Cardellini - SD A.A. 2010/11 18

10 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 (aggiornata continuamente) 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 Valeria Cardellini - SD A.A. 2010/11 19 Bootstrap server n1 n2 n3 Un peer può rifiutare una richiesta di connessione, ad esempio perché ha raggiunto un numero massimo di connessioni ammesse Valeria Cardellini - SD A.A. 2010/11 20

11 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 Valeria Cardellini - SD A.A. 2010/11 21 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 Valeria Cardellini - SD A.A. 2010/11 22

12 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 Valeria Cardellini - SD A.A. 2010/11 23 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 Valeria Cardellini - SD A.A. 2010/11 24

13 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... Valeria Cardellini - SD A.A. 2010/11 25 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 Valeria Cardellini - SD A.A. 2010/11 26

14 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 Valeria Cardellini - SD A.A. 2010/11 27 Seeder Tracker statistics Leecher Peer list Approccio tit-for-tat (strategia di teoria dei giochi) 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 Stimola la collaborazione fra i peer (collaborazione iniziale) Limita il free riding Free rider: esegue solo download, senza contribuire alla rete Valeria Cardellini - SD A.A. 2010/11 28

15 Seeder: peer che possiede una copia completa del file All inizio deve esistere almeno un seeder (da cui viene scaricato almeno una volta tutto il file) 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 Valeria Cardellini - SD A.A. 2010/11 29 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 Possibili tracker multipli 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) Valeria Cardellini - SD A.A. 2010/11 30

16 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 Valeria Cardellini - SD A.A. 2010/11 31 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 Valeria Cardellini - SD A.A. 2010/11 32

17 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 Valeria Cardellini - SD A.A. 2010/11 33 No allocazione centralizzata della banda di upload Ogni peer peer ha un numero limitato di slot di upload da allocare agli altri peer ed applica una strategia per massimizzare la sua velocità di download Strategia di tipo tit-for-tat per allocare gli slot di upload Obiettivo: scambio tra banda in upload e banda in download ed evitare la presenza di peer solo in download e non in upload Il peer può rifiutare di concedere l upload ad un altro peer (choking: strozzatura della connessione verso il peer non cooperativo) Ottimizzazione globale perseguita cercando di ottimizzare gli interscambi locali 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 Valeria Cardellini - SD A.A. 2010/11 34

18 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 (valore medio calcolato su 20 sec) Lista dei peer abilitati ricalcolata ogni 10 sec Per evitare di trascurare canali promettenti si attua l abilitazione ottimistica (optimistic unchocking) 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 Valeria Cardellini - SD A.A. 2010/11 35 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 Valeria Cardellini - SD A.A. 2010/11 36