Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
A.A. 2004-2005
UNIVERSITÀ DEGLI STUDI DI PADOVA
Dipartimento di Ingegneria dell’Informazione
Corso di Laurea in Ingegneria Informatica
TESI DI LAUREA
PROGETTAZIONE E
REALIZZAZIONE IN JAVA DI UNA
RETE PEER TO PEER ANONIMA E
MULTIFUNZIONALE
A.A. 2004-2005
Ai miei genitori
chi mi hanno sempre sostenuto
incoraggiato e aiutato.
Indice
Sommario 1
Introduzione 3
1 Le caratteristiche peculiari 7
1.1 Architettura a plug-in . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Serverless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Anonimato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 I crediti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Le componenti 15
2.1 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.2 Connettività . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Kademlia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Altri plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.1 Web server (http) . . . . . . . . . . . . . . . . . . . . . . 28
2.3.2 E-mail (smtp, pop3) . . . . . . . . . . . . . . . . . . . . . 29
2.3.3 Host resolution (dns) . . . . . . . . . . . . . . . . . . . . . 30
2.3.4 File sharing (aMule) . . . . . . . . . . . . . . . . . . . . . 30
3 Management 33
Conclusioni 37
v
INDICE
A.1.4 Datagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.2 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.2.1 The core . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.2.2 Resource manager . . . . . . . . . . . . . . . . . . . . . . . 49
A.2.3 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Bibliografia 53
vi
Sommario
1
Citiamo qui solo Boinc http://boinc.berkeley.edu/.
2
http://www.emule-project.net/
3
Uno su tutti: Cina, anche Google accetta la censura
http://www.corriere.it/Primo Piano/Scienze e Tecnologie/2006/01 Gennaio/25/
google.shtml
Introduzione
Gli esempi più famosi di reti di questo tipo sono quelle dedicate allo scambio
di file: in principio si trattava di file musicali (MP3), poi si è arrivati allo scambio
di qualsiasi genere di file. Queste reti, nonostante la loro natura distribuita, basa-
vano il loro funzionamento su dei server. Questi servivano a mettere in contatto
tra loro i vari nodi della rete, senza però prendere mai parte al trasferimento dei
file. Tuttavia, è chiaro che in caso di irraggiungibilità di questi server, la rete non
poteva sussistere proprio perché i vari nodi non avrebbero potuto comunicare tra
loro. Esempi di questo tipo di rete sono la rete eDonkey2000 (d’ora in poi ED2K),
ancor oggi usata da celebri programmi come mlDonkey, eMule, aMule e la rete
Bittorrent5 col suo famoso client Azureus.
Per rendere la rete più resistente al black out di qualunque dei computer ad
essa collegati sono stati sviluppati protocolli di gestione completamente decen-
tralizzati6 . Questi protocolli cercano di affidare a ogni nodo che concorre alla
formazione della rete l’indicizzazione di alcuni file, in modo che ogni file faccia
riferimento ad un nodo attivo, e sia quindi rintracciabile. Alcuni protocolli di
questo tipo sono Chord7 , Pastry8 , ma soprattutto Kademlia. Quest’ultimo, che
4
[4]
5
Cfr. [5]
6
Protocolli DHT: Distributed Hash Table.
cfr. http://en.wikipedia.org/wiki/Distributed hash table
7
Cfr. [6]
8
Cfr. [7]
3
INTRODUZIONE
sembra essere il più promettente, viene già sfruttato nelle recenti versioni di quasi
tutti i client per la rete ED2K.
Un altro aspetto poco desiderabile delle reti P2P è il fatto che, anche in
una rete completamente serverless, è piuttosto semplice riuscire a scoprire quali
nodi (quali indirizzi IP) condividono quali file. La privacy degli utenti della
rete non è, quindi, per nulla garantita. Questo problema è stato affrontato e
risolto da recenti reti, come Ants e Mute, che si avvalgono di tecniche come
il routing probabilistico9 . Queste reti sono però, tuttora, reti di nicchia, vista
l’esigua dimensione che raggiungono, proprio perché la garanzia dell’anonimato
dell’utente tende a rendere la ricerca meno efficiente e, quindi, spesso, più lenta.
Tuttavia il fattore che maggiormente contribuisce a contenere la dimensione di
queste reti, è il cosiddetto effetto rete 10 .
Accanto a queste reti, che hanno come scopo il trasferimento file, vivono
altri progetti con obiettivi diversi. Citiamo qui Freenet11 , che fornisce servizi di
webhosting anonimo e Skype12 che gestisce un sistema di VOIP su una rete P2P.
Uno dei problemi principali che hanno affrontato queste reti è stato come
invogliare l’utente a condividere i propri file. Per risolvere questo problema le
reti si sono spesso basate su un sistema di gestione di crediti virtuali. Il sistema
che sembra funzionare meglio13 è quello adottato dalla rete ED2K. Proviamo a
spiegare come funziona con un semplice esempio. Se Alice scarica un file da Bob,
Alice è in debito verso Bob e, quindi, Bob potrà saldare il credito scaricando i
file di Alice prima degli altri eventuali concorrenti. Questo sistema ha però una
grossa pecca: Bob, infatti, sarà in credito solo con Alice e con nessun altro nodo
della rete, nonostante la partecipazione alla rete e la condivisione dei file rendano
un servizio (per quanto ipotetico) a tutti i nodi.
PariPari è una rete serverless basata su una variante di kademlia, garantisce
l’anonimato dei suoi nodi, fornisce un sistema di crediti più intelligente di reti
come ED2K, e, soprattutto, è multifunzionale. È probabilmente la multifunziona-
lità l’aspetto più innovativo di questo progetto (e probabilemte la sfida più grande
che ci siamo posti). Lo scopo è, infatti, quello di distribuire sulla rete tutti i più
comuni servizi disponibili su internet, mantendendoli però raggiungibili e fruibili
anche da computer esterni a PariPari. Per raggiungere questo obiettivo è stato
scelto un approccio a plug-in. Attorno a un nucleo centrale (detto core) viene
9
Cfr. [8]
10
Cfr. http://en.wikipedia.org/wiki/Network effect
11
http://freenetproject.org/
12
http://www.skype.com/
13
Valutandolo in base al numero di utenti
4
gradualmente costruita una galassia di plug-in che saranno in grado di interagi-
re tra loro e con internet per fornire i più disparati servizi. Questa architettura
permette di poter aggiungere alla rete nuovi servizi, qualora ce ne sia la necessità.
PariPari si propone, quindi, di creare una macchina virtuale capace di prov-
vedere a tutti i bisogni dell’utente di internet mantendosi dipendente solo dalla
comunità dei nodi da cui è formata.
5
INTRODUZIONE
6
Capitolo 1
Le caratteristiche peculiari
7
1. LE CARATTERISTICHE PECULIARI
Un altro punto di forza della rete è la fruibilità dei servizi anche dall’esterno.
Infatti, i client che partecipano alla rete possono utilizzare le risorse condivise da-
gli altri nodi; elemento di novità è che la rete potrà essere sfruttata da computer
non facenti parte di PariPari. Ad esempio, se all’interno della rete, Alice si pro-
pone come webserver e Bob le fornisce una sua pagina, la pagina sarà consultabile
da qualsiasi computer connesso a internet con un normale browser.
Vista la natura aperta al pubblico e agli sviluppatori della rete si è deciso che
il progetto sarà open source e rilasciato sotto licenza GPL1 .
8
1.2 SERVERLESS
1.2 Serverless
PariPari deve il suo successo alla possibilità di funzionare senza richiedere ai
suoi utenti di permanere collegati ad essa perennemente. D’altra parte, non è
consigliabile mantenere una struttura centralizzata della rete, tramite dei nodi
principali, proprio perché l’indisponibilità di quest ultimi disgregherebbe la rete
intera.
9
1. LE CARATTERISTICHE PECULIARI
1.3 Anonimato
In una rete P2P, e quindi anche in PariPari, le transizioni di risorse (file, cicli
macchina,...) avvengono sempre tra due nodi della rete. Il nostro sistema di ano-
nimato permette di effetture questo contatto senza che sia possibile rintracciare
l’indirizzo IP del mittente nè quello del ricevente. Senza addentraci in una de-
scrizione troppo approfondita che sarà esposta in [3], diamo una descrizione dei
tratti salienti del funzionamento di questo sistema.
Premettiamo che ogni volta che si parlerà di crittografia si intenderà un pro-
cesso misto tra crittografia simmetrica e asimmetrica. Attualmente, infatti, i
dati sottoposti a cifratura, vengono prima passati all’algoritmo a chiave segreta
AES e poi, solo la chiave viene passata all’algoritmo RSA con chiave pubblica
privata a 2048 bit3 . La crittografia sui byte viene affidata ad un algoritmo molto
veloce, mentre a quello molto più lento viene lasciata la crittografia solo della
chiave simmetrica (della dimensione di pochi byte). In questo modo si possono
sfruttare i benefici derivanti dall’uso di algoritmo a chiave asimmetrica pagando
solo marginalmente la sua effettiva lentezza.
2
Sarebbe più corretto dire che tutti i nodi sono punti con la stessa debolezza.
3
La limitazione 2048 bit è imposta dalle JCE della Sun per restrizioni sull’esportazione di
tecnologia crittografica fuori dagli USA.
10
1.4 I CREDITI
Il sistema permette all’utente della rete di creare tra sè e il suo interlocutore
una catena di nodi, e altrettanto può fare l’interlocutore stesso. Il mittente, e
simmetricamente il ricevente, prima di iniziare la trasmissione, sceglie una catena
di nodi intermedi, ognuno dei quali ignora l’esistenza e quindi l’identità degli altri
nodi formanti la catena. Vengono quindi passate le richieste tra i due interlocu-
tori attraverso questi tunnel con un meccanismo di onion routing che permette
la segretezza dei dati trasportati dai nodi e la sicurezza della comunicazione. I
dati, infatti, sono cifrati con le chiavi pubbliche in modo che solo il nodo che in
quel momento deve ricevere, ed eventualemente rispedire, il pacchetto di comu-
nicazione può leggerne il contenuto. È evidente che, quanto più le catene sono
lunghe, tanto è maggiore la sicurezza offerta all’utente, d’altra parte, aumentando
il numero di salti e di passaggi crittografici aumenta anche la latenza nei trasferi-
menti e nelle ricerche. Inoltre, l’uso dell’onion routing, aumenta il carico di banda
complessivo per la rete in modo proporzionale al numero di salti.
Riportiamo solamente qui un risultato discusso in[3]:
Si mette quindi a disposizione di ogni nodo una tecnologia che mira a garantire
la privacy dell’utilizzatore. Inoltre, l’utente può scegliere se usare o meno questo
sistema, indipendentemente dalla scelta effettuata dal suo interlocutore.
1.4 I crediti
La gestione dei crediti in una rete P2P potrebbe sembrare un argomento di se-
codaria importanza, visto che non ne migliora le prestazioni, nè ne aumenta le
caratteristiche. Tuttavia è uno dei punti cruciali di queste reti perché regola
11
1. LE CARATTERISTICHE PECULIARI
Alice Bob
12
1.4 I CREDITI
13
1. LE CARATTERISTICHE PECULIARI
3. il nodo si sconnette e non torna mai più con quella identità in rete;
4
Cfr. John R. Doceur, The Sybil Attack
14
Capitolo 2
Le componenti
2.1 Core
Il core assolve a due funzioni principali: caricare le classi già compilate che
contengono i plug-in e permettere ai plug-in di comunicare tra loro.
Per concedere la più ampia libertà possibile agli sviluppatori dei plug-in abbia-
mo cercato di limitare al massimo le richieste dell’interfaccia. Al momento, non
è addirittura possibile specificare un interface dato che l’unica richiesta strin-
gente è un vincolo sul costruttore. Al costruttore del plug-in, infatti, è necessario
passare come argomento il monitor del core. Se poi, come sembra evidente, il
plug-in necessita di comunicare con altri plug-in, lo sviluppatore portà spedire al
e ricevere dal monitor i messaggi di cui ha bisogno.
Il caricamento dinamico delle classi già compilate è stato affrontato ponendo
delle blande restrizioni sui nomi che le classi possono assumere e usando i package
di Java java.lang.ClassLoader e java.lang.reflect. Il nome che assume la
classe, e quindi anche il costruttore, è assunto come identificativo univoco del
plug-in per tutto il tempo in cui rimane attivo. Viene, quindi, passata la lista dei
nomi delle classi, che deve caricare, al core. Quest’ultimo carica le classi e invoca
i costruttori passando loro come argomento il monitor.
Il core, al momento della creazione degli oggetti plug-in, associa ad ognuno
una coda prioritaria. Ogni coda è assegnata ad un plug-in e contraddistinta dal
nome del plug-in stesso. Il plug-in, a questo punto, per comunicare con un suo
15
2. LE COMPONENTI
16
2.1 CORE
pari, semplicemente inserisce la sua richiesta nella coda del destinatario. L’even-
tuale risposta gli verrà recapitata direttamente nella propria coda. Il ricevente
deve continuare a fare polling della propria coda in attesa di messaggi diretti a
lui. Questo ciclo infinito tenderebbe a sprecare le risorse del sistema; proprio per
questo abbiamo scelto di usare la PriorityBlockingQueue. Questa struttura
dati già presente nelle JDK dalla versione 1.5, porge due caratteristiche molto in-
teressanti. In primo luogo incorpora nella coda già un monitor. Questo permette
al thread, che controlla la coda in attesa di nuovi messaggi, di andare in uno stato
di wait in caso di coda vuota e di non sprecare risorse. In secondo luogo poi, la
coda gestisce un sistema di priorità definibile sulla base di un comparatore che
abbiamo noi stessi specificato. In questo modo, in caso di congestione del core, si
può sperare che i messaggi con priorità più alta arrivino comunque a destinazione,
consentendo al core stesso di mantenere le sue normali funzionalità.
Da alcune prove che abbiamo eseguito, questo sistema sembra comportarsi
secondo le attese. Tuttavia possono sorgere problemi nel caso i plug-in produca-
no messaggi a una velocità molto maggiore della velocità con cui li consumano.
In tale evenienza, infatti, le code si riempiono e tendono a saturare la memoria
della JVM. Questo comporta il lancio di un’eccezione e l’arresto di tutto il core.
Per fronteggiare il problema, si è provveduto a limitare il numero di messaggi che
possono essere contemporaneamente in una coda, scartando gli ulteriori even-
tuali messaggi in arrivo. Questo escamotage, che sembra funzionare secondo le
previsioni, è tuttavia ampiamente migliorabile. Sarebbe auspicabile, infatti, un
controllo sulla priorità del pacchetto prima di decidere se scartarlo, o meno o
anche un approccio di tipo RED[2].
Questa struttura con un grosso monitor dotato di code è stato scelto per ov-
viare ad alcune limitazioni di Java. Se i plug-in avessero comunicato direttamente
tra loro senza passare da un monitor, ci sarebbe stato sicuramente un incremento
delle prestazioni (ci sarebbe stato, infatti, un passaggio in meno). In C/C++ si
sarebbero probabilmente potuti usare i puntatori per affrontare il problema. In
Java ci siamo invece affidati all’uso di un monitor opportunamente modificato:
una soluzione che permette anche di controllare i flussi di messaggi tra i plug-in.
Vediamo ora cosa sono esattamente questi messaggi. I messaggi trasmessi
tra i vari plug-in sono dei pacchetti caratterizzati quasi come dei datagrammi di
networking. Ognuno di questi pacchetti è formato da diversi campi che servono
ad indicare la provenienza e la destinazione del pacchetto, la priorità e il pay-
lod. Questi pacchetti, che abbiamo chiamato cocoon, corrispondono, se vogliamo
continuare il nostro parallelo col mondo delle reti, a datagrammi ip. Il payload
17
2. LE COMPONENTI
Nel pacchetto core sono anche inseriti i manager per le risorse. Questi moduli
hanno il compito di assegnare e, in caso di conflitto, arbitrare le risorse. Queste
operazioni però, non dipendono esclusivamente dal resource manager competen-
te. L’assegnazione, infatti, si basa su un meccanismo che coinvolge il plug-in
richiedente e il modulo per la gestione dei crediti. Il plug-in che vuole usufruire,
ad esempio, di una certa quantità di spazio su disco, deve, infatti, richiederne
l’uso al gestore locale ma deve anche “pagare” al modulo per la gestione dei cre-
diti. La transazione tende a complicarsi nel caso in cui è un altro nodo della rete
a interrogare il client locale per usarne lo spazio. Infatti, il nodo remoto, deve
prendere contatto col plug-in locale per controllare la disponibilità del servizio,
e, poi, deve interagire col modulo di gestione crediti per accordarsi sul prezzo.
In locale, il plug-in accetta di fornire il servizio al nodo remoto previa verifica
di pagamento presso il modulo gestione crediti. Successivamente si fa carico di
chiedere l’allocazione della risorsa presso il gestore della risorsa competente. Il
gestore dovrà quindi, oltre ad accettare le richieste dei plug-in, controllare pre-
18
2.1 CORE
• Spazio su disco;
• cicli macchina;
• connettività:
– velocità;
– latenza;
– assenza di jitter.
Da queste risorse, che possono essere sfruttare dai vari plug-in, è possibile ricavare
diversi servizi. Si pensi, ad esempio, come un servizio di web hosting faccia uso
contemporaneamente di spazio su disco e connettività. In questo modo, all’utente,
è rischiesto di gestire servizi finiti, mentre la scomposizione di questi in risorse è
lasciata ai plug-in e ai gestori delle risorse.
Passiamo ora a illustrare i gestori delle risorse attualmente inclusi nel core.
2.1.1 Storage
Come già detto precedentemente, i gestori, hanno la medesima struttura dei plug-
in, si differenziano da essi solo per la loro funzione. I gestori, infatti, sono il
tramite tra il core, e i suoi plug-in, e le risorse della macchina su cui gira il client.
Essi, infatti, amministrano spazio su disco, banda e, nel futuro, cicli macchina.
dataStorage è il gestore che sovraintende lo spazio su disco. Attualmente pre-
senta una struttura piuttosto semplice, perché gestisce solamente qualche opera-
zione su file in locale. Questo gestore gestisce file interi tramite un handler di
Java. In questo modo il passaggio di un file da una parte all’altra del client non
comporta nessun accesso al disco, eliminando uno dei possibili colli di bottiglia del
client. Oltre file interi dataStorage lavora anche su pezzi di file, chiamati chunk.
dataStorage può ricevere da un plug-in dei chunk, senza che questi seguano ne-
cessariamente un ordine, e riassemblare il file, mantendo opzionalmente un certo
controllo nella ricostruzione. Questo gestore, infatti, può controllare che i chunk
19
2. LE COMPONENTI
Erasure coding
Questo, che è uno degli aspetti più innovativi di tutto il progetto, verrà qui solo
accennato senza alcuna pretesa di completezza. Sarà, infatti, esposto nella tesi di
Federico Sogaro. Scopo dell’erasure coding è modificare un file aggiungendo un
piccolo overhead in modo tale che in caso di irrecuperabilità di alcune sue parti il
file sia comunque ricostruibile. Uno schema di funzionamento possibile, anche se
descritto in maniera volutamente molto semplificata su un ipotetico file da 100
MB, segue.
20
2.1 CORE
2.1.2 Connettività
Questo secondo gestore presiede alla trasmissione e alla ricezione di byte. Il
package permette l’invio e la ricezione dati su protocollo udp e tcp. Scendere a
livello del protocollo ip non è purtroppo stato possibile dato che java non prevede
nativamente questa possibilità. A onor del vero usando alcune librerie come le
jpcap sarebbe stato possibile manipolare i pacchetti ip. Questo risultato sarebbe
arrivato però ad un costo troppo alto. Infatti le jpcap sono solo un wrapper
attorno alle celeberrime pcap (scritte in C). Usarle si sarebbe tradotto in:
È chiaro che sono due condizioni che avrebbero troppo pesato sull’utente finale.
I plug-in che desiderano ricevere pacchetti dall’esterno, al loro avvio, preno-
tano una porta. Il gestore inoltrerà loro tutto quello che arriverà su quella porta
corredato con informazioni ausiliarie come la porta e l’indirizzo ip di partenza.
1
Cfr. http://sgharea.dyndns.org/mediawiki/index.php/Distributed Storage
2
Cfr. http://punto-informatico.it/p.asp?i=53935
21
2. LE COMPONENTI
Nel caso di comunicazioni su tcp, il plug-in che riceve il datagramma può spedire
la risposta sullo stesso socket su cui è arrivato il datagramma stesso.Il problema
non si pone per comunicazioni udp o singole tcp.
Connectivity verrà presto migliorato aggiungendo la possibilità di limitare la
banda da usare. Inoltre, nel momento in cui il modulo di anonimato risulterà
pronto, l’infrastruttura è disegnata per accoglierlo senza cambiare praticamente
nulla nel codice. Ai plug-in, quindi, basterà cambiare un campo nei messaggi
inviati a questo gestore per avvalersi di queste due nuove funzionalità.
2.2 Kademlia
Kademlia, come già annunciato, è il protocollo di ricerca su cui si basa PariPari
per essere completamente serverless. Inizialmente, abbiamo cercato di imple-
mentare quanto descritto nel paper di Petar Maymounkov e David Mazi‘eres [1]
quanto più fedelemente possibile.
22
2.2 KADEMLIA
Successivamente il nodo contatta i nodi i cui ID sono molto vicini all’hash delle
sue risorse e comunica loro le coordinate per essere raggiunto. In questo modo
ogni hash viene assegnato al nodo che più gli è vicino e la ricerca di una risorsa si
riduce alla ricerca di un nodo della rete. Il nodo che vuole cercare un altro nodo
nella rete conoscendone l’ID contatta i nodi che già conosce richiedendo infor-
mazioni sull’oggetto della sua ricerca. I nodi interrogati rispondono fornendogli
l’elenco dei nodi più vicini di cui loro hanno notizia. Successivamente, il nodo
cercatore, iterativamente, interrogherà dalla lista dei nodi ricevuti i più vicini a
quello cercato finchè questo ciclo non lo condurrà a contattare il nodo che voleva
trovare (vedi 2.2).
A cerca Z.
Volendo si può visualizzare questo schema di lavoro come una discesa lungo un
albero binario in cui le foglie corrispondono ai nodi della rete. Ad ogni salto della
ricerca si procede verso il basso escludendo mezzo sotto-albero fino ad arrivare
alla foglia cercata.
Per realizzare questo sistema abbiamo proceduto per fasi. Abbiamo prima
individuato la struttura interna che avrebbe dovuto avere il plug-in per poter sal-
vare, come descritto in [1], le informazioni riguardo i nodi con cui sarebbe entrato
23
2. LE COMPONENTI
0 1
00 01 10 11
Figura 2.3: Albero di Kademlia: ad ogni salto durante la discesa si elimina mezzo
sotto-albero.
• Ping;
• Find Value;
• Find Node;
• Store.
24
2.2 KADEMLIA
comunicazioni = (distanza − 1) · 2
comunicazioni = distanza − 1
25
2. LE COMPONENTI
26
2.2 KADEMLIA
27
2. LE COMPONENTI
Quest’ultima scelta però non assicura ancora che la ricerca tramite prediletto
termini con successo. Sarebbe più efficace che ogni nodo eleggesse un nume-
ro costante di prediletti; quest’approccio tuttavia comporterebbe l’esplosione del
problema inondando la rete di prediletti e, quindi, di comunicazioni. Sarebbe
preferibile riuscire ad utilizzare più di una catena di prediletti. Questo garan-
tirebbe una certa parsimonia nelle comunicazioni e una probabilità maggiore di
arrivare velocemente al nodo cercato. Ancora migliore sarebbe la possibilità di
far interagire le diverse catene di prediletti in modo che il loro numero sia sempre
costante. Nel caso una di queste arrivasse in un vicolo cieco potrebbe rigenerarsi
a partire da un nodo diverso fornito da un’altra catena. Questi, appena elencati,
sono i possibili miglioramenti che verranno nel prossimo futuro studiati e, quindi,
applicati al progetto.
Ci sono poi una serie di altri plug-in cui si procederà alla realizzazione quanto
prima:
• newsgroup (nntp);
• chat (irc);
28
2.3 ALTRI PLUG-IN
ip dinamico
ip dinamico
ip dinamico
ip statico
stmp.gmail.com
29
2. LE COMPONENTI
30
2.3 ALTRI PLUG-IN
4
Tipico caso di effetto rete. Cfr. http://en.wikipedia.org/wiki/Network effect
31
2. LE COMPONENTI
32
Capitolo 3
Management
Per affrontare un progetto cosı̀ vasto e diversificato, abbiamo proceduto alla crea-
zione di un gruppo di ricerca. L’importanza di questa organizzazione risulta ancor
più evidente pensando che i lavori proseguiranno per almeno un altro paio d’anni.
La presenza di un gruppo ben organizzato mette il progetto al riparo da evenienze
come la morte prematura dello stesso per abbandono dei partecipanti.
La struttura modulare del progetto ha, in qualche modo, suggerito un ap-
proccio divide and conquer. Ad ogni laureando, infatti, sono state assegnate la
progettazione e la realizzazione di uno o più plug-in (secondo la complessità del
plug-in e il tipo di laurea da conseguire.), sempre sotto la supervisione e il con-
trollo di quello che potremmo chiamare il coordinatore. Scopo del coordinatore
è proprio quello di assegnare i lavori (in accordo col prof. Peserico) e controllare
come questi vengano progettati e implementati. Ha anche la funzione di esperto
on-line per quegli studenti che non hanno ancora maturato una certa esperienza
di progettazione e programmazione in Java. Il coordinatore è anche il punto di
comunicazione tra gli studenti e il professore. Questo compito, oltre a permettere
di raccogliere le domande per riformularle in modo più efficiente e conciso per
l’interazione col relatore, genera una specie di effetto caching. Spesso, infatti, i
problemi sollevati sono uguali o simili tra loro, e perciò possono essere risolti in
modo più veloce. L’ultima funzione del coordinatore, ma forse la più significativa,
è proprio quella di rappresentare il trait d’union tra gli stessi coordinatori. Per
non disperdere il know-how è oltremodo importante che il coordinatore provveda
a trasferire le proprie conoscenze non scritte e documentate al suo successore.
Per progetti cosı̀ estesi, è molto utile per gli sviluppatori presenti e futu-
ri, la possibilità di comprendere la struttura e il funzionamento di quanto già
scritto. Per adempiere a questa necessità, ad ogni sviluppatore è richiesto di
commentare pesantemente il codice prodotto, e di scrivere qualche pagina di do-
33
3. MANAGEMENT
34
3.0
cumentazione. Abbiamo scelto di adottare come lingua del progetto l’inglese per
evidenti motivi di internazionalizzazione. L’idea, poi, di fare ospitare il progetto
su sourceforge.net avvalora ancora di più questa scelta.
Nonostante la natura modulare, che permette il lavoro quasi indipendente
dei membri del gruppo, abbiamo trovato grossissimi problemi di comunicazione.
Tutti i moduli, infatti, devono cooperare tra loro ed è essenziale per i vari svi-
luppatori scambiarsi idee, consigli e richieste. Purtroppo, non è sempre stato
semplice gestire in modo organico le comunicazioni e le richieste dei vari studenti.
35
3. MANAGEMENT
36
Conclusioni
Abbiamo già notato, in questi pochi mesi di vita, come non sia per nulla semplice
gestire un progetto cosı̀ ambizioso. Oltre i problemi di ordine tecnico e logistico
che, in qualche modo, sono stati risolti, continuano a presentarsi problemi di or-
dine logico. Abbiamo tentato di mantenere la struttura del core il più semplice e
funzionale possibile1 proprio per permettergli di crescere e fornire tutte le funzio-
nalità che gli saranno richieste in futuro. Purtroppo, nonostante questo sforzo di
progettazione, è già accaduto di dover riscrivere completamente un modulo2 per
aggiungergli nuove caratteristiche indispensabili ad altri plug-in. È prevedibile
che, nonostante tutto, da oggi al giorno del lancio al pubblico del client, moltis-
simi altri saranno i problemi e le conseguenti correzioni in itinere. La speranza è
quella di avere impostato il progetto in modo che questi aggiustamenti in corso
d’opera siano i più semplici e più efficienti possibili, garantendo il migliore dei
substrati possibili per i plug-in presenti e futuri.
1
Principio KISS http://en.wikipedia.org/wiki/KISS principle
2
È stato completamente riscritto il modulo di connettività: Connectivity
37
CONCLUSIONI
38
Appendice A
A.1 Kademlia
This document describes our Kademlia implementation. This client is intended
to run over a connectivity layer allowing high scalability and high modularization.
Byte arrays moving between the Kademlia layer and connectivity layer are mana-
ged by a simple monitor. Kademlia, as described in [1], uses four logic RPC and
several ADT that store information about the net around a node. A description
of the implementation of the four RPC follows. We explain choices and policies
and finally most important pieces of code.
The main class of the package is KadAdt that provides all the primary low
level methods to operate on the basic structure of Kademlia. Besides this object
other threads maintain data consistency and the node running1 .
We analyze the whole package keeping in mind how it works, giving a tran-
sversal view of the involved classes.
A.1.1 ADT
In a Kademlia client there are three different main data structures.
39
Documentazione del progetto
Table of buckets
This table is built directly in the constructor of the class KadAdt. It is implemen-
ted by an array of Object. Each of these Object is an instance of different sizes2
dopArray.
dopArray is built coupling two simple arrays:
1. Long[];
2. tripla[].
The first one stores a long value3 that represents the timestamp obtained
running the java method System.currentTimeMillis. A -1 value in this field denotes
an empty tripla. So the erasing procedure4 consists simply in putting a -1 in
the long cell.
The second array holds instances of the class tripla.
int port represents the port address on which the node is listening;
This table is built using brand new own made class called triplArray. This class
is composed by three different simple arrays:
1. Long[];
2. Byte[];
3. Object[].
The first one stores a long value5 that represents the timestamp obtained
running the java method System.currentTimeMillis. A -1 value in this field denotes
2
The size of the dopArray is defined according to the kademlia policies.
3
A long encapsulated in a Long.
4
And the initialization.
5
A long encapsulated in a Long.
40
Appendice
Table of store
There are two different tables: the table that stores the node’s own links and the
table to store the link from other clients. They have the same structure and they
are implemented by the class store. This class is composed by three different
simple arrays:
1. Long[];
2. Vector[];
3. String[].
The first one stores a long value7 that represents the timestamp obtained
running the java method System.currentTimeMillis. A -1 value in this field denotes
an empty tripla. So the erasing procedure8 consists simply in putting a -1 in
the long cell.
The third field holds the hash of the resource whose link had to be saved.
Finally in the second field the client keeps a collection of instances of tripla,
that refers to the third field.
Besides this two tables, there is another thread called kadStore that keeps
the two tables refreshed. Continuously, at pre-defined time intervals, it deletes
the obsolete entries in the table that hosts external information and republishes
in the net the old entries in the other table.
6
And the initialization.
7
A long encapsulated in a Long.
8
And the initialization.
41
Documentazione del progetto
A.1.2 Communication
Since now we call communication the RPC and its reply. We’ve defined a
datagram for each communication; all of them have one header in common9 .
Here some more words about the third and the fourth field.
The type field describes the type of the datagram that follow. For each RPC
is assigned a byte value as you can see in this list.
1 ping;
2 ping reply;
4 ping check;
7 fing node;
9 fing value;
13 store.
The random byte field is filled by four bytes randomly generated by the
client who send the request. The recipient replies embedding these four bytes
in the answer, this way the sender can understand the match for the answer to
the question. Moreover this practice increases the security level against malicious
datagram sent to a client.
9
Other parts of the datagram are in common but at the moment they aren’t in the header
in order to keep a more logic structure of the datagram.
42
Appendice
Ping
This statement expresses the basic role of this RPC. Whenever a node receives
a ping, it answers and adds the sender to his table of buckets; the same
behavior must be honored for any other RPC received. Whenever a client receives
a ping it replies to the source with a ping reply (with ping reply) and then calls
the method insNodo. So the source receives the ping reply and processes it with
ping sink and erases from the table of random byte the random bytes of the
first request.
insNodo provides the functionalities to insert the node passed as argument
in the table of buckets. It calculates the distance with XOR metric10 and
selects the right bucket for insertion. If the bucket has at least one free cell the
node is straitforward inserted; otherwise the so called kadInsert thread is run.
kadInsert searches the right bucket11 for the oldest inserted node and then
tries to ping check12 it. If the old node replies, kadInsert refreshes the node in
the bucket; otherwise it replaces it with the new one.
Store
STORE instructs a node to store a (key; value) pair for later retrieval
43
Documentazione del progetto
Find Node
Find Value
As mentioned in A.1.2 the class that performs this kind of search is still
kadSearcher. The behaviour to find a value is very very similar to that to find
a node. Now we consider only the differences.
The recipient of a fing value checks its table of store to find recurrences of
the searched hash. If found it replies with fing reply sending the correct tripla16 .
15
fing sink in class kadAdt.
16
Otherwise it follows the behaviour of find node
44
Appendice
This is a variation on Find Node and Find Value introduced to half the round trip
time. The searching node, while it proceeds with the default searching behaviour,
chooses a favorite among the nodes it is going to contact. This favorite node, other
than answering the searcher, chooses a favorite, called child, among the nodes it
is going to send to the requesting node. The favorite node asks its child directly
for the searched ID or hash and to choose another child to continue the chain of
favorites.
A.1.3 Classes
Here is a list of classes with a brief description.
45
Documentazione del progetto
A.1.4 Datagrams
Here is a list of datagrams with a brief description.
Header
Byte Use Note
0 KaD version the version of the datagram
1,2 size the size of the whole datagram (max 64KB)
3 type the nature of the datagram
4,5,6,7 random byte
tripla
0,1,2,3 IP the tripla’s IPv4
4,5 port the tripla’s listening port
6 + hash length ID the tripla’s ID
Ping
Store
46
Appendice
Find Node
Find Node
Find Value
Find Value
Other notes: the random bytes are the same20 along the whole favorites chain.
20
Decided by the first node.
47
Documentazione del progetto
A.2 Core
This document describes the implementation of the core. The core is designed to
be as simpler as possible keeping the ability to manage the most different kinds
of plug-in.
The core is formed by two main structures and it is surrounded by two resource
managers. The main purpose of the core is to launch the plug-ins and to provide
to them a structure to communicate. The resource managers are inteded to let
the plug-ins use local resource such as disk capacity and connectivity.
• the core has to pass to the plug-in, as an argument, the object manager21 ;
orig a String that indicates the plug-in that generates this cocoon;
leave a String containing the name of the plug-in to which sending the answer.
21
That represent the core itself
48
Appendice
Connectivity
This resource manager provides the functionality to send and receive streams of
byte over internet. The message for this plug-in is the object flux:
This resource manager handles both the udp and the tcp protocol. A plug-in
that wants to use a port to listen on, sends a “book” request to Connectivity.
All the traffic towards that port will be forwarded to the booking plug-in. In
case of tcp communication the plug-in can re-use the same socket from which it
received the data.
dataStorage
This resource manager provides the functionality to save and retrieve files24 . The
message for this plug-in is the object chunk:
position a long that indicates the offset to start writing or reading from;
49
Documentazione del progetto
destination a String containing the name of the plug-in to send the answer to;
This plug-in can undertake three different operations. It can manage entire
files, it can operate over pieces of file in a dumb mode or in an ensured mode.
Entire files are simply handled with the handler of java. This resource manager
allows the plug-ins to deal with pieces of file. It can assemble the pieces to make
a whole file or it can read pieces in any order from (un)complete files. While
assembling, it can check for overlapping problems avoiding them.
A.2.3 Classes
Here is a list of classes with a brief description.
50
Appendice
51
Documentazione del progetto
52
Bibliografia
[7] http://research.microsoft.com/~
antr/PAST/pastry.pdf.
53
BIBLIOGRAFIA
54
Elenco delle figure
55
ELENCO DELLE FIGURE
56
Elenco delle tabelle
57
ELENCO DELLE TABELLE
58
Ringraziamenti
— Guglielmo di Occam