A2-03 Applicazioni Peer to Peer

Transcript

1 A2-03 Applicazioni Peer to Peer Dopo aver esaminato le applicazioni di rete che utilizzano l'architettura clientserver, analizziamo più approfonditamente l'architettura peer-to-peer che, come abbiamo visto all'inizio del capitolo, prevede la connessione diretta e intermittente tra coppie di host. I peer che comunicano tra loro, quindi, non appartengono a un fornitore di servizi, ma sono periferiche controllate direttamente dagli utenti. Nel seguito esamineremo due applicazioni tipiche di questa architettura, che ne esemplificano chiaramente la struttura ed i vantaggi: la distribuzione di file, che mostra chiaramente l'autoscalabilità del P2P, ed un database distribuito tra una grande comunità di peer. Distribuzione di file peer to peer La distribuzione di file con architettura client-server prevede che un server o, quasi sempre, un gruppo di server invii un file a un gran numero di host: ciò richiede un forte consumo di banda da parte del server ed un enorme carico di lavoro. Nella distribuzione di file P2P, ogni peer può ridistribuire qualsiasi parte del file che ha ricevuto ad altri peer, aiutando in tal modo il server nella distribuzione. Attualmente, il più popolare protocollo per la distribuzione di file P2P è BitTorrent: utilizzeremo, quindi, questo protocollo per descrivere l'architettura della distribuzione di file P2P. File F Server u1 us d1 u2 dn d2 Internet un u3 d5 u5 d4 u4 d3 Per illustrare la intrinseca autoscalabilità del P2P, consideriamo un semplice modello quantitativo per la distribuzione di un file a un insieme fisso di peer. Questo file costituisce un espansione online del corso Informatica di Addomine, Pons Zanichelli Editore S.p.A.

2 Come mostrato in figura 1, server e peer sono connessi a Internet tramite link di accesso. Chiamiamo u s la velocità di upload del server, u i la velocità di upload e d i la velocità di download dell'i-esimo peer. Chiamiamo F la dimensione del file da distribuire (in bit) e N il numero di peer che vogliono ottenere una copia del file. Il tempo di distribuzione è il tempo necessario perché tutti gli N peer ottengano una copia del file. Per semplicità, ipotizziamo che la banda disponibile sull'ìinternet sia tale da non generare colli di bottiglia, quindi che il tempo di distribuzione dipenda solo dalla velocità dei link di upload e download; ipotizziamo anche che sia il server che i peer non utilizzino contemporaneamente altre applicazioni di rete, ossia che la banda di accesso sia interamente dedicata alla distribuzione del file. Determiniamo il tempo di distribuzione per l'architettura client-server, che chiamiamo D cs, notando che: il server deve trasmettere una copia del file ad ognuno degli N peer, per cui deve trasmettere NF bit: poiché la velocità di upload del server è u s, il tempo di distribuzione del file deve essere NF/u s la velocità di download dei peer non è identica, per cui esiste un d min appartenente al peer con la connessione più lenta, ossia d min = min(d 1, d 2,.,d n ) Unendo queste due affermazioni, otteniamo che D cs = max(nf/u s, F/d min ) Per quanto sia grande la banda di upload del server, al crescere del numero dei peer,troviamo che per cui si ha D cs = NF/u s. U s < sum(d 1, d 2,.,d n ) Da ciò si deduce che, per un numero elevato di peer, il tempo di distribuzione cresce linearmente con il numero di peer: se il numero dei peer cresce di 10 volte, anche il tempo di distribuzione decuplica. Nell'architettura P2P, ogni peer può assistere il server, ridistribuendo immediatamente quanto ricevuto, utilizzando il proprio link di upload: il calcolo del tempo di distribuzione diventa più complesso, ma può essere espresso in modo altrettanto semplice. Notiamo che: all'inizio della distribuzione, solo il server contiene il file. Per inviarlo alla comunità dei peer, deve effettuare l'upload almeno una volta attraverso il proprio link di accesso, quindi il minimo tempo di distribuzione lato server è almeno F/u. A differenza dell'architettura client-server, infatti, può non essere necessario più di un invio da parte del server, dato che i peer possono ridistribuire il file tra loro autonomamente come nell'architettura client-server, il peer con la connessione più lenta non può ricevere in un tempo minore di F/d min la capacità totale di upload del sistema nel suo insieme è pari alla velocità di

3 upload del server, più le velocità di upload di ogni singolo peer, ossia u tot = u s + u 1 + u u n. Poiché il sistema deve trasmettere globalmente NF bit, il tempo minimo di distribuzione non può essere inferiore a NF/(u s + u 1 + u u n ) Se chiamiamo DP2P il tempo di distribuzione del sistema peer-to-peer, troviamo che D P2P = max{f/u s, F/d min, NF/(u s + u 1 + u u n ) La figura 2 mostra il diverso andamento del tempo di distribuzione tra le due architetture, in funzione del numero di peer. Tempo minimo di distribuzione 3,5 3,0 2,5 2,0 1,5 1,0 0,5 Client-server P2P N Abbiamo posto, per semplicità, che tutti i peer abbiano la stessa velocità di upload u e che F/u = 1h, u s = 10u, d min u s. Ciò significa che un peer può trasmettere il file in un'ora, il server è 10 volte più veloce dei peer e la velocità di download è tale da non avere effetto sul tempo di trasferimento. Si vede chiaramente come, nell'architettura client-server, il tempo di distribuzione cresca linearmente con il numero di peer; nell'architettura P2P, invece, il tempo di distribuzione tende asintoticamente a F/u, garantendo così l'autoscalabilità del sistema indipendentemente dal numero di host connessi. Bit Torrent Come abbiamo detto, BitTorrent è il più popolare protocollo di distribuzione file P2P. Nel gergo di BitTorrent, l'insieme di tutti i peer che partecipano alla distribuzione di un particolare è detto torrent. I peer di un torrent si scambiano tra loro chunk (letteralmente blocco, porzione) del file, con una dimensione tipica di 256 KB.

4 Quando un peer entra in un torrent non possiede alcun chunk, ma col passare del tempo ne accumula una quantità sempre maggiore e, al contempo, li distribuisce ad altri peer. Quando ha scaricato l'intero file, il peer può lasciare il torrent, oppure rimanere e continuare ad inviare chunk ad altri peer entrati più recentemente. Il funzionamento di BitTorrent è piuttosto complesso, per cui ci limiteremo a descriverne il meccanismo principale. Ogni torrent possiede un nodo infrastrutturale chiamato tracker. Facendo riferimento alla figura 3, quando un nuovo peer entra nel torrent, si registra sul tracker e periodicamente lo informa di essere ancora presente: in questo modo, il tracker tiene un elenco dei peer che, in ogni momento, stanno partecipando al torrent. Tracker Peer Lista dei peer Scambio di chunk Nuovo peer All'entrata del peer, il tracker seleziona in maniera casuale un sottoinsieme tra i peer partecipanti che chiameremo per comodità vicini e ne invia l'indirizzo IP al nuovo entrato, che tenta di stabilire una connessione TCP contemporanea con tutti i peer della lista. Con il passare del tempo, alcuni vicini possono uscire dal torrent mentre altri, entrati successivamente, possono tentare la connessione TCP e diventare a loro volta vicini: si vede chiaramente come la comunità dei vicini, all'interno del torrent, cambi continuamente e come un torrent possa avere durata illimitata, proseguendo sino a che esiste almeno un peer che desidera il file e almeno un altro peer disposto a inviarlo. Poiché il file viene scambiato non nella sua interezza, ma in chunk, durante il trasferimento ogni peer ha un sottoinsieme dei chunk del file, differente per ognuno: periodicamente, ogni peer chiede ai suoi vicini, tramite la connessione TCP, l'elenco dei chunk che ognuno possiede. Questo file costituisce un espansione online del corso Informatica di Addomine, Pons Zanichelli Editore S.p.A.

5 In questo modo, può generare una lista di chunk, verificare quali non sono ancora in suo possesso ed inviare ai vicini la richiesta di download. Per effettuare queste operazioni in modo efficiente, il peer deve prendere due decisioni: la sequenza dei chunk da richiedere e la scelta di quali saranno i vicini di cui esaudirà le richieste. Per definire la sequenza delle richieste, viene usata la tecnica detta rarest first, ossia prima il più raro: vengono determinati i chunk presenti sul minor numero di vicini, ossia quelli di cui esistono meno copie contemporaneamente, e richiesti per primi. In questo modo, i chunk più rari sono ridistribuiti più velocemente, allo scopo di equalizzare per quanto possibile il numero di copie di tutti i chunk all'interno del torrent. Per definire a quali richieste rispondere, BitTorrent usa un algoritmo di scambio molto intelligente. La regola base è che viene data priorità ai vicini che stanno a loro volta inviando dati alla maggiore velocità: viene misurata la velocità di invio e scelti i quattro vicini più veloci, cui vengono inviati i propri chunk. Ogni 10 secondi, le velocità sono ricalcolate ed il gruppo dei quattro destinatari eventualmente modificato. Nel gergo di BitTorrent, questi quattro vicini sono detti unchoked, termine intraducibile che deriva dalla negazione del verbo to choke, soffocare, strozzare, intasare. Oltre a ciò, ogni 30 secondi, il peer invia chunks ad un quinto vicino, scelto in modo casuale, iniziando uno scambio; se entrambi i peer sono soddisfatti dello scambio, si inseriscono vicendevolmente nella lista degli unchoked e continuano a scambiarsi choke sino a che uno dei due trova un socio migliore. L'effetto di questo comportamento è che i peer capaci di effettuare upload a velocità simili tendono a trovarsi. La selezione casuale del vicino, inoltre, permette ai peer nuovi entrati di riceve dei chunk, quindi di avere qualcosa da scambiare. DHT (Distributed Hash Tables) Immaginiamo di avere un semplice database, formato da una tabella con due sole colonne, chiave e valore. Per fare qualche esempio esempio, la chiave può essere il codice fiscale ed il valore il nome della persona (PNSDNL54D10E704O, Daniele Pons), oppure la chiave è il nome di un contenuto ed il valore l'indirizzo IP dove questo è registrato (The Dark Side of the Moon, ). Interroghiamo il database attraverso la chiave: se vi sono una o più coppie chiave-valore che corrispondono alla query, il database restituisce i valori corrispondenti. Realizzare un simile database è elementare, se utilizziamo un'architettura clientserver, che mantiene tutte le coppie in un unico server: noi, però, ne vogliamo costruire una versione distribuita P2P che registri le coppie chiave-valore su un gran numero di peer. Nel sistema P2P, ogni peer conterrà solo un piccolo sottoinsieme delle coppie, e qualunque peer potrà interrogare il database con una chiave qualunque: il database distribuito localizzerà i peer che contengono la coppie corrispondenti e le invierà alla sorgente della query. Ogni peer, infine, potrà inserire nuove coppie nel database.

6 Un simile database distribuito viene chiamato DHT (Distributed Hash Tables). Vediamo per prima cosa come funziona un servizio DHT all'interno di un file sharing P2P, usando l'esempio nome di contenuto - indirizzo IP. Poniamo di voler scaricare una copia dell'ultima release di una distribuzione Linux e che questa sia contenuta nei peer Rosso e Bianco; inoltre, esiste un ulteriore Peer che è responsabile del contenuto, generalmente quello che l'ha immesso nel database, che chiamiamo Verde. Se vogliamo ottenere una copia di Linux, per prima cosa dobbiamo sapere in che peer è disponibile: inoltriamo, quindi, una query con chiave "Linux" al database DHT. Il database determina che il responsabile per la chiave "Linux" è Verde, contatta il peer Verde, ne ottiene le due coppie Linux-IP rosso e Linux-IP bianco e le passa a Verde, che può scaricare la distribuzione sia da Rosso che da Bianco. Vediamo come è possibile progettare un simile database. La soluzione più semplice è, ovviamente, quella di distribuire a caso le coppie su tutti i peer partecipanti e costringere ogni peer a mantenere in memoria la lista di tutti gli indirizzi IP. Il peer che vuole trovare i valori corrispondenti, invia la query della chiave a tutti i partecipanti, e tutti i peer che contengono una coppia con quella chiave rispondono. Il sistema può funzionare per qualche decina di peer, ma sicuramente non per i milioni di partecipanti che generalmente compongono questi database distribuiti: si tratta di un approccio totalmente non scalabile e, quindi, improponibile. Esiste una soluzione al problema molto più elegante. Iniziamo assegnando ad ogni peer un identificativo, composto da un intero compreso nell'intervallo [0, 2 n -1] con n dato e fisso, in modo che ogni identificativo possa essere espresso da un numero di n bit. Richiediamo, poi, che ogni chiave sia composta da un intero compreso nella stessa gamma di valori. Questa condizione è impossibile da soddisfare, se usiamo come chiave nomi di contenuti, codici fiscali o, in realtà, qualunque altra cosa che abbia riferimento diretto al mondo reale: per creare interi partendo da queste chiavi, usiamo una funzione hash (letteralmente tritare, sminuzzare, pasticciare) che mappa ogni chiave in un intero compreso nell'intervallo [0, 2 n -1]. Una funzione hash è una funzione molti a uno, per la quale due diversi ingressi possono avere la stessa uscita, ossia lo stesso intero, ma le probabilità che ciò avvenga sono estremamente basse. La funzione hash deve essere disponibile a tutti i peer del sistema. Da qui in avanti, quando ci riferiamo alla "chiave" intendiamo l'hash della chiave originale: se, ad esempio, la chiave originale è "The Dark Side of the Moon", la chiave effettivamente utilizzata dal DHT è l'intero corrispondente all'hash di "The Dark Side of the Moon". Consideriamo adesso come memorizzare le coppie chiave-valore nel DHT: il problema centrale, in questo caso, è la definizione di una regola di assegnazione delle chiavi ai peer. Dato che ogni peer ha un identificatore intero e che anche ogni chiave è un intero nello stesso intervallo, l'approccio più intuitivo è assegnare ogni coppia al peer il cui identificatore è il più prossimo alla chiave.

7 Per implementare questo schema, dobbiamo definire cosa intendiamo con il termine "più prossimo", per il quale sono possibili molte convenzioni diverse: per comodità, definiamo come peer più prossimo quello immediatamente successivo alla chiave. Per fare un esempio molto semplice, supponiamo che n = 4, cosicché gli identificatori dei peer e le chiavi cadono nell'intervallo [0, 15]; supponiamo, inoltre, che nel sistema vi siano 8 peer, con identificativo 1, 3, 4, 5, 8, 10, 12 e 15; infine, supponiamo di voler inserire la coppia (11, Daniele Pons) in uno degli 8 peer. Usando la convenzione dichiarata, la coppia verrà registrata sul peer 12, che è il successivo più vicino. Se la chiave corrisponde esattamente all'identificatore di un peer, la coppia verrà registrata sul peer corrispondente. Se, invece, la chiave ha un valore superiore a tutti gli identificativi, utilizziamo il complemento a 2, registrando la chiave nel peer con l'identificativo più basso. Supponiamo, adesso, che un peer voglia inserire una nuova coppia chiave-valore nel DHT. Concettualmente, non ci sono problemi: si determina qual è il peer con identificatore più prossimo e di invia a questo la coppia. Ma, per fare ciò, ogni peer dovrebbe avere l'elenco di tutti gli identificativi: oltre al fatto che il DHT varia dinamicamente, può succedere che il sistema contenga milioni di peer e, quindi, la cosa sia praticamente improponibile. La determinazione del peer più prossimo, indipendentemente dalla convenzione adottata, comporta una serie di problemi architetturali, la cui esposizione eccede gli scopi di questo libro. Per finire, notiamo come i DHT abbiano trovato un'ampia applicazione pratica. Ad esempio, BitTorrent usa il DHT kademlia per creare un tracker distribuito: in questo caso, la chiave è l'identificativo del torrent ed il valore è l'indirizzo IP di tutti i peer partecipanti al torrent. In questo modo, interrogando il DHT con un identificatore di torrent, un nuovo arrivato può identificare il peer responsabile del tracking e chiedergli un elenco degli altri peer partecipanti al torrent. Didascalie Figura 1 Figura 2 Figura 3 Distribuzione di file peer-to-peer Tempo di distribuzione nelle architetture client-server e P2P Distribuzione di file con BitTorrent