HOME

PROGETTI

SOFTWARE

CURRICULUM

  

Client Torrent Parallelo

 Questo progetto è stato realizzato insieme a Marco Ferrara e all' Ing. Salvatore Distefano

Funzionamento generale:

Lo scopo di questo progetto é di riuscire a parallelizzare il protocollo BitTorrent, in modo da velocizzare il download di un file.

Per la realizzazione del client torrent, é stato necessario utilizzare le seguenti librerie di sviluppo:

-- LIBBOOST librerie per la compilazione di codice scritto in linguaggio C++

-- LIBTORRENT libreria scritta in linguaggio C++ che permette la realizzazione di un client torrent, con capacitá, nel caso di connessioni a banda larga, di download ed upload superiore a quella di un client ufficiale.

-- MPI (Message Passing Interface) protocollo di comunicazione tra nodi appartenenti ad un cluster di computer che eseguono un programma parallelo. (Per questo progetto é stata utilizzata la versione MPICH2)

Implementazione del client:

Il client realizzato, per effettuare il download di un file, esegue le seguenti fasi:

-- Decodifica del file torrent: tale fase é interamente gestita dalla classe LibTorrent; in particolare la selezione del percorso é stata organizzata secondo il seguente schema:

> Se il rank corrisponde a 0, il percorso é impostato su ~/condivisa/. > Se il rank é diverso da 0 il percorso é impostato su /mnt/condivisa dove tale cartella corrisponde alla cartella ~/condivisa/ del rank 0. Quindi é ovvio che per permettere lo scaricamento del file da parte delle macchine con rank diverso da 0, bisogna precedentemente montare la cartella condivisa.

-- Selezione del modo di storage: tale selezione permette all'algoritmo di poter scrivere il file su disco attraverso tre strategie: storage_mode_allocate, storage_mode_sparse, storage_mode_compact. Per capirne la differenza, si considera una situazione dove il file da scaricare occupa 12 Mb e il cluster é formato da n=4 macchine. Con storage_mode_allocate sono creati n file di dimensione pari alla dimensione del file da scaricare. Si avrá quindi all'interno della cartella condivisa del rank 0, 4 file da 12 Mb ciascuno. Con storage_mode_sparse sono creati n file con dimensioni circa pari al numero del rank per la divisione totale del file d'origine, diviso il numero di macchine del cluser (se il rank=2, sará creato un file pari a (2*12)/4=6 Mb). Si avrá rispettivamente per ogni macchina, 1 file da 3 mb, 1 da 6 mega, 1 da 9 e un altro da 12 e con ad esclusione del rank 0, i primi 3,6,9 mega dei file settati a 0. Con storage_mode_compact sono creati n file con dimensione pari al numero di byte scaricati. Si avrá rispettivamente per macchina 1 file da 4 Mb. Ai fini del progetto realizzato si é scelta la strategia storage_mode_sparse, perché tale tecnica mantiene la corretta posizione dei chunk tra le parti. Nella figura sotto sono spiegate in modo grafico tali suddivisioni.

-- Scaricamento del file: Tramite le funzioni di inizializzazione dell'MPI, si é a conoscenza della grandezza del cluster e quindi del numero di macchine di cui é composto. Dato che il file é diviso in chunk, ovvero in frammenti che devono essere scaricati dal cluster, quindi dalle singole macchine, si puó immaginare che ogni macchina del cluster scaricherá un numero di chunk pari al numero di chunk totale diviso il numero di macchine. Tale ragionamento non presenta nessun problema nel momento in cui da tale rapporto si ottiene modulo pari a 0. Infatti nel caso in cui il resto é diverso da 0 non si otterrebbe la totalitá del download del file, pregiudicando la correttezza del file stesso. Per tale motivo sono stati implementati due metodi che si occupano dei due casi sopracitati. Nel caso in cui il modulo é pari a 0, é fatta la semplice divisione dei chunk da scaricare per macchina, mentre nel caso in cui il modulo é diverso da 0 é eseguita una particolare funzione: supponendo che il cluster é formato da 4 macchine e che il numero di chunk é pari a 1002; in tale situazione, saranno scaricate per macchina 250 parti con un resto pari a 2. Al fine di bilanciare il download dei chunk restanti, si é pensato di suddividere le parti restanti nelle n macchine, piú che far scaricare le restanti parti ad una sola macchina (ad esempio la prima). In tal caso ogni macchina scarica al più 1 solo chunk. Nell'esempio riportato sopra quindi, si avrá la seguente suddivisione:

Questa operazione di suddivisione dei chunk, é realizzata dal rank 0, che provvedderá una volta calcolati i range, a spedirli alle altre macchine. Successivamente tutte le macchine del cluster provvedderano a settare la prioritá dei chunk da scaricare ( attraverso la funzione set_priority ) impostando la priorità dei chunk da scaricare a 1 (normal priority) in base al range inviato dal rank 0.

-- Assemblaggio del file ricevuto: Al completamento del download delle n macchine, si procederá alla fase di assemblaggio.

L'assemblaggio consiste nello scrivere nel file provvisorio 1, le parti in verde del file provvisorio 2 e del file provvisorio 3, tale da ottenere il file finale.

Creazione della rete torrent:

Durante alcuni test, si era constatato che la velocitá di download del client parallelo era uguale o per di piú superiore a quella di un normale single-client torrent, senza quindi ottenere il beneficio sperato. La causa responsabile di tale lacuna era semplicemente dovuta al ritardo del trasferimento delle parti fra i client, quindi una soluzione per risolverla é stata quella di separare le due fasi ( download e assemblaggio ) in due reti separate:    - RETE 1: Download delle parti ( a media velocitá )    - RETE 2: Trasferimento delle parti fra i client ( ad alta velocitá )

A livello pratico si é pensato di simulare una situazione simile ad un'infrastruttura di rete presente in un edificio di N piani, dove per ogni piano é presente una connessione ADSL (con una velocitá non superiore ai 20 Mb) impiegata per il download dei file, ed una rete lan interna all'edificio ( avente una velocitá superiore ai 20 Mb ) da utilizzare per lo scambio delle parti fra i N piani. Utilizzando quindi una seconda rete per il trasferimento delle parti, si é potuto rendere indipendente il trasferimento dal download.

Analisi delle prestazioni:

Ai fini di studio le misure sono state eseguite con tre client e con quattro file rispettivamente di dimensione: 50 MB, 100MB, 250 MB e 500 MB. Si é osservato come all'aumentare dei client, il tempo totale di download rispetto ai precedenti diventa sempre meno significativo, facendo presupporre che per un numero elevato di client, il sistema puó stabilizzarsi ad un tempo costante, dovuto sicuramente, dall'aumentare del tempo di assemblaggio, crescente in modo proporzionale al numero di pezzi scaricati.

I grafici riferiti allo Speedup ed alla Efficienza ottenuta in funzione della dimensione del file scaricato e del numero di client utilizzati sono: