tesi_Lelli_Matteo_finale

ALMA MATER STUDIORUM - UNIVERSITÀ DI BOLOGNA
SCUOLA DI INGEGNERIA E ARCHITETTURA
CORSO DI LAUREA IN INGEGNERIA INFORMATICA
DIPARTIMENTO DI INFORMATICA – SCIENZA E INGEGNERIA
TESI DI LAUREA
in
Tecnologie Web T
Gestione Dinamica del Piazzamento
di User-generated Content
in Reti Ibride Fisse/Mobili
CANDIDATO RELATORE
Matteo Lelli Chiar.mo Prof. Ing. Paolo Bellavista
CORRELATORE
Dott. Ing. Carlo Giannelli
Anno Accademico 2012/13
Sessione II

I
Parole chiave: Sistemi Distribuiti
Pervasive Computing
Caching Attivo/Passivo
Spontaneous Networking
Content Placement

III
INDICE
Introduzione .................................................................................... 1
CAP.1 Introduzione ai sistemi di caching in reti P2P.................. 3
1.1 Reti strutturate e reti non strutturate ........................................ 3
1.1.1 Reti non strutturate............................................................. 3
1.1.1.1 Esempi di reti P2P non strutturate ............................. 5
1.1.2 Reti strutturate.................................................................... 6
1.1.2.1 Esempi di reti P2P strutturate .................................... 7
1.1.3 Modelli ibridi ....................................................................... 8
1.1.3.1 Esempi di reti P2P basate su modelli ibridi................ 8
1.2 Caching in reti P2P .................................................................. 8
1.2.1 Caching in reti P2P gestite da un ISP................................ 9
1.2.2 Caching in reti P2P senza ISP......................................... 15
1.3 Considerazioni conclusive ..................................................... 21
CAP.2 Middleware RAMP............................................................. 23
2.1 Reti spontanee....................................................................... 23
2.2 Scenari applicativi.................................................................. 25
2.2.1 File sharing....................................................................... 26
2.2.2 Videoconferenze .............................................................. 26
2.2.3 Consegna di messaggi critici ........................................... 28
2.3 Linee guida per middleware SN............................................. 28
2.4 Architettura............................................................................. 29
2.4.1 Strategie di gestione dei pacchetti ................................... 30
2.4.1.1 Nonreliable Bulk Transfer ........................................ 31
2.4.1.2 Reliable Packet Streaming....................................... 31
2.4.1.3 Highly Reliable Message Delivery ........................... 32
2.5 Estensioni del middleware RAMP.......................................... 33
2.5.1 Multi-hop UPnP Carrier.................................................... 33

IV
2.5.2 Extended RAMP Network ................................................ 34
2.6 Condivisione basata sulle relazioni sociali............................. 35
CAP.3 Gestione dinamica di user-generated content in reti
spontanee......................................................................... 39
3.1 Analisi contesto preesistente ................................................. 39
3.2 Analisi del problema............................................................... 44
3.2.1 Possibili casi d’uso........................................................... 44
3.2.1.1 File Sharing Service in una rete ad-hoc................... 44
3.2.1.2 File Sharing Service attivo su device Android.......... 45
3.3 Politiche di monitoraggio e di re/placement ........................... 46
3.4 Architettura della soluzione.................................................... 50
3.4.1 Monitoraggio del traffico di File Sharing........................... 50
3.4.2 Cache passiva.................................................................. 51
3.4.3 Cache proattiva................................................................ 51
3.4.4 Soluzione complessiva..................................................... 52
3.5 Realizzazione implementativa ............................................... 52
3.5.1 Implementazione del monitoraggio del traffico di File
Sharing........................................................................... 53
3.5.2 Implementazione della cache passiva ............................. 56
3.5.2.1 Implementazione di FileSharingPacketListener....... 57
3.5.2.2 Implementazione di FileSharingCacheManager ...... 59
3.5.2.3 Implementazione di PlacementStrategy .................. 60
3.5.2.4 Implementazione di ReplacementStrategy .............. 62
3.5.2.5 Implementazione di CachedFiles............................. 62
3.5.3 Implementazione della cache proattiva............................ 63
3.5.3.1 Implementazione di FileSharingCacheService ........ 66
CAP.4 Risultati sperimentali........................................................ 67

V
4.1 Test della cache passiva........................................................ 67
4.1.1 Predisposizione test della cache passiva......................... 68
4.1.2 Risultati ottenuti dal test della cache passiva................... 69
4.1.3 Analisi risultati test della cache passiva........................... 71
4.2 Test cache proattiva............................................................... 71
4.2.1 Predisposizione test della cache proattiva....................... 71
4.2.2 Risultati ottenuti dal test della cache proattiva................. 74
4.2.3 Analisi risultati ottenuti dal test della cache proattiva....... 75
Conclusioni ................................................................................... 77
APPENDICE A: diagrammi UML .................................................. 79
A1 FileSharingTransferHeader.......................................... 79
A2 FileSharingTrafficObserver ....................................... 80
A3 FileSharingPacketListener.......................................... 81
A4 PacketComposer ................................................................. 82
A5 FileSharingCacheManager.............................................. 83
A6 CachedFiles........................................................................ 84
A7 FileSharingCacheCacheRequest ................................... 85
A8 FileSharingCacheCacheService ................................... 86
Bibliografia.................................................................................... 87
Ringraziamenti.............................................................................. 88

1
INTRODUZIONE
Una significativa porzione del traffico Internet è oggigiorno generata
da applicazioni peer-to-peer (P2P) per servizi quali streaming,
telefonia o File Sharing. Queste applicazioni stanno diventando
sempre più popolari poiché costituiscono una soluzione a basso
costo al problema del reperimento delle risorse da parte degli utenti
di Internet. Per avere un’idea della vastità e dell’importanza della
diffusione delle reti P2P sono sufficienti i seguenti dati relativi a due
famose applicazioni: Napster (http://www.napster.com) raggiunse un
picco di 26,4 milioni di utenti connessi contemporaneamente nel
febbraio 2001 mentre eMule (http://www.emule-project.net) può
vantare una media di 3,5 milioni di client e di circa 4 miliardi di file
disponibili. In presenza di un traffico così vasto e imponente, risulta
evidente come la progettazione di soluzioni di ottimizzazione possa
arrecare un grande beneficio sia dal punto di vista degli utenti finali, i
quali potranno godere di una migliore qualità del servizio, sia dal
punto di vista degli operatori dell’infrastruttura, i quali potranno
alleviare il carico sulle loro reti ottenendo benefici strutturali ed
economici.
Contemporaneamente alla crescita delle reti P2P, negli ultimi anni il
mercato dell’elettronica di consumo è stato caratterizzato
dall’emergere di un vasto ecosistema di dispositivi eterogenei
contraddistinti da capacità sempre più grandi e dalla possibilità di
condividere contenuti multimediali generati dall’utente. Quindi, da un
lato, aumenta l’intenzione da parte degli utenti di voler condividere i
contenuti da loro generati sulla base delle relazioni personali e
sociali che intercorrono con le altre persone. Tuttavia, dall’altro lato,
si vuole avere il pieno controllo dei propri contenuti, specialmente se
attinenti alla propria sfera personale, decidendo ad esempio da chi e
quando possono essere acceduti. È proprio in questo scenario, che
nasce il middleware RAMP [RAMP], creato con lo scopo di gestire in
maniera flessibile, dinamica e lato-applicazione il traffico di reti P2P
spontanee.

2
Il lavoro di questa tesi si inserisce proprio in questo contesto. In
particolare, l’obiettivo è creare un nuovo sistema software in grado
di monitorare il traffico di File Sharing generato attraverso il
middleware RAMP e di gestire dinamicamente il piazzamento dei
contenuti prodotti dall’utente in reti ibride formate sia da dispositivi
fissi sia da dispositivi mobili. Infatti, il nuovo sistema software sarà in
grado di effettuare caching passiva dei file passanti attraverso un
determinato nodo su cui è attivo RAMP e, in seguito, di fornirli
direttamente al client richiedente. In aggiunta, saranno studiate ed
implementate nuove politiche di gestione del piazzamento dei
contenuti generati dagli utenti, con particolare attenzione al contesto
di mobilità ed eterogeneità hardware delle reti ibride. Infine, sarà
progettato un nuovo servizio di cache, il quale permette di richiedere
proattivamente e da remoto i file che sono stati precedentemente
aggiunti alla cache. Questo nuovo servizio diventa particolarmente
importante in reti ibride in cui sono presenti collegamenti UMTS.
Infatti, in queste reti sarà possibile diminuire drasticamente il
numero di byte scambiati attraverso la connessione UMTS,
riducendo di conseguenza la latenza delle richieste dei file e
aumentando la qualità finale del servizio di File Sharing offerto dal
middleware RAMP.
In particolare, nel Capitolo 1 verrà descritta l’architettura P2P e la
sua struttura, fornendo diversi esempi di reti P2P. Verranno inoltre
analizzate possibili soluzioni di caching delle risorse nell’ambito
delle reti P2P. Nel Capitolo 2 verranno studiare le reti spontanee
con particolare riferimento al middleware RAMP. Nel Capitolo 3
saranno analizzate le problematiche risolte dal lavoro di tesi e
saranno discusse le scelte implementative. Infine, nel Capitolo 4
saranno esposti diversi test sperimentali e i risultati ottenuti.

3
CAP.1
INTRODUZIONE AI SISTEMI DI CACHING IN RETI P2P
Una rete peer-to-peer (P2P) è un tipo di architettura di rete
decentralizzata e distribuita in cui ogni nodo nella rete (chiamato
peer) agisce sia come fornitore che come consumatore di risorse.
Questa architettura è in contrasto con il modello centralizzato client-
server, in cui i nodi client richiedono risorse fornite da uno o più
server centralizzati. Una rete P2P è dunque progettata sul concetto
di nodi equivalenti che si comportano simultaneamente sia come
client sia come server degli altri nodi sulla rete.
In particolare, una rete P2P implementa generalmente un layer
logico che si appoggia alla topologia fisica della rete, in cui i nodi
presenti nello strato superiore sono un sottoinsieme dei nodi del
livello fisico. In questo modo, i nodi del livello applicativo potranno
creare connessioni logiche fra loro e comunicare gli uni con gli altri,
mentre al livello fisico i dati continueranno a essere scambiati
direttamente fra i peer.
Nel Paragrafo 1.1 verranno analizzate due principali categorie di reti
P2P, le reti strutturate e quelle non strutturate, mentre nel paragrafo
1.2 saranno esaminate strategie di caching di risorse specifiche per
reti P2P.
1.1 RETI STRUTTURATE E RETI NON STRUTTURATE
Sulla base di come i nodi di reti P2P sono connessi tra di loro a
livello di rete e sulla base di come le risorse sono indicizzate e
gestite, è possibile classificare questo tipo di reti in due principali
categorie: strutturate e non strutturate. Nei seguenti paragrafi (1.1.1
e 1.1.2) saranno descritte le principali caratteristiche di queste
categorie, riportando alcuni esempi ed introducendo un’ulteriore
categoria intermedia formata dai modelli ibridi (paragrafo 1.1.3).
1.1.1 RETI NON STRUTTURATE
Una rete P2P non strutturata non impone nessun vincolo strutturale
specifico allo strato logico sovrastante all’atto della progettazione.
Viceversa, queste tipologie di reti sono formate da nodi che si

4
connettono casualmente gli uni agli altri, come illustrato
schematicamente nell’esempio della Figura 1.
Figura 1. Il diagramma di una possibile rete P2P non strutturata illustra la natura ad
hoc delle connessioni tra i diversi nodi
A causa dell’assenza di una struttura globale imposta su di esse, le
reti non strutturate sono facili da costruire e consentono
ottimizzazioni localizzate a regioni differenti dello strato superiore.
Inoltre, poiché il ruolo di ogni nodo nella rete è lo stesso, le reti non
strutturate sono molto robuste di fronte ad alti livelli di churn, cioè
quando un grande numero di nodi entra e lascia la rete
frequentemente.
Tuttavia, i principali svantaggi di questo tipo di reti derivano proprio
dalla loro intrinseca mancanza di struttura. Una delle situazioni più
emblematiche di questa carenza è forse la ricerca di un dato
all’interno della rete. Infatti, nel caso in cui si intenda ricercare una
risorsa o parte di essa, la query di ricerca viene tipicamente inviata
in flooding attraverso tutta la rete, in modo da raggiungere tutti i nodi
che condividono il dato ricercato. È evidente che questo flooding di
richieste provoca un grosso overhead nell’uso delle risorse, sia per
quanto riguarda il traffico di rete sia per quanto riguarda il consumo
di CPU, memoria e, conseguentemente, di energia dei singoli nodi.

5
Inoltre, non è detto che questo sforzo aggiuntivo si traduca
necessariamente nella localizzazione della risorsa richiesta. Infatti,
non c’è la garanzia che il flooding della query produca un esito
positivo in quanto non vi è certezza che si troverà un nodo
contenente il dato richiesto. Ad esempio, la ricerca di un dato
popolare risulta facilmente soddisfacibile in quanto il dato è
posseduto da molti nodi. Viceversa, la ricerca di una risorsa
posseduta solamente da poche persone in una rete di grandi
dimensioni sarà raramente soddisfatta (almeno in tempi accettabili).
1.1.1.1 Esempi di reti P2P non strutturate
Esempi di protocolli utilizzati in reti P2P non strutturate sono
Gnutella, Gossip e Kazaa. In particolare, il protocollo Gnutella
[RIP01] è un protocollo di adesione e di ricerca in una rete P2P
aperta e decentralizzata, principalmente utilizzato per il file sharing.
Spesso con il termine Gnutella si indica anche la rete virtuale
stessa, formata essenzialmente da due tipi di nodi: gli ultrapeer,
nodi accessibili da Internet e caratterizzati da un’alta banda e lunghi
periodi di connessione, e i nodi foglia, che sono nodi ordinari
connessi solamente agli ultrapeer e spesso risiedenti in reti private.
Inoltre, i nodi di una rete Gnutella sono stati chiamati dagli
sviluppatori servent (dall’unione delle parole server e client), poiché
svolgono compiti normalmente associati sia ai server sia ai client.
Infatti, essi forniscono interfacce lato client dove l’utente può
eseguire ricerche e visualizzarne i risultati, ma allo stesso tempo
accettano query da altri servent, cercano corrispondenze con i loro
dati locali e rispondono con i risultati ottenuti. Inoltre, questi nodi
sono anche responsabili di gestire il traffico di background che
diffonde le informazioni utilizzate per mantenere l’integrità della rete.
Infine, i nodi decidono in che punto connettersi alla rete logica
sovrastante solo in base alle informazioni locali. In questo modo si
forma una rete dinamica e auto-organizzata di entità indipendenti.
Nella Figura 2 è riportato un grafico di una piccola porzione del layer
logico di una rete Gnutella, in cui si può osservare l’assenza di una
struttura nelle connessioni tra i nodi.

6
Figura 2. Lo snapshot delle connessioni in una rete Gnutella locale.
1.1.2 RETI STRUTTURATE
Nelle reti P2P, lo strato logico sovrastante al livello fisico è
organizzato in una specifica topologia e il protocollo di
comunicazione garantisce che la ricerca di una risorsa sia efficiente
(tipicamente O(log N), dove N è il numero di nodi della rete), anche
se la risorsa ricercata è estremamente rara.
Il tipo più comune di reti P2P strutturate implementa una tabella
hash distribuita (distributed hash table – DHT) in cui si usa una
variante del consistent hashing per mappare il possesso di ogni
singola risorsa ad un nodo specifico. In questo modo i nodi possono
ricercare le risorse sulla rete semplicemente usando una tabella
hash, cioè recuperando agevolmente il valore associato ad una
chiave data, come schematizzato nell’esempio in Figura 3.

7
Figura 3. Il diagramma di una possibile rete P2P strutturata, la quale usa una DHT
per identificare e localizzare i nodi e/o le risorse
In altre parole, esiste un legame tra l’identificativo di una risorsa e
l’indirizzo del peer che possiede tale risorsa.
Tuttavia, per consentire un routing efficiente del traffico, ogni nodo di
una rete strutturata deve mantenere una lista dei vicini che
soddisfino criteri specifici. Ciò rende la rete meno robusta in
situazioni in cui vi è un grande numero di nodi che si uniscono o
lasciano la rete.
1.1.2.1 Esempi di reti P2P strutturate
Esempi notevoli di reti distribuite che usano DHT includono il tracker
distribuito di BitTorrent, la rete Kad, Storm botnet, YaCy e Coral
Content Distribution Network. In particolare, la rete Kad è una nota
rete P2P che implementa il protocollo P2P di overlay Kademlia.
Kademlia (sviluppato nel 2002 da P. Maymounkov e D. Mazières)
sfrutta una DHT per strutturare la rete e per lo scambio di
informazioni attraverso la ricerca dei nodi (che comunicano tra loro
utilizzando UDP). La rete virtuale o overlay è formata dai nodi
partecipanti in cui ognuno di essi è identificato da un node ID. Esso
serve non solo all’identificazione, ma è anche utilizzato

8
dall’algoritmo di Kademlia per localizzare le risorse, solitamente
attraverso l’hash di un file o una parola parole chiave. Infatti, il node
ID fornisce direttamente una mappa di hash e il nodo corrispondente
all’ID memorizza le informazioni su come ottenere tale risorsa o file.
In particolare, quando si ricerca un valore, l’algoritmo necessita di
conoscere la chiave associata ed esplora la rete in diversi passi. In
ogni passo troverà nodi sempre più vicini alla chiave fino a che il
nodo contattato restituirà il valore o fino a quando non sono stati
trovati nodi più vicini. Questa ricerca è molto efficiente: come molti
altri protocolli DHT, Kademlia contatta solo O(log(N)) nodi durante la
ricerca su un totale di N nodi nel sistema.
1.1.3 MODELLI IBRIDI
I modelli ibridi sono una combinazione di modelli peer-to-peer e
modelli client-server. Un tipico modello ibrido è costituito da un
server centrale che aiuta gli altri nodi a trovarsi.
Vi è una vasta gamma di modelli ibridi, ma tutti essi costituiscono un
punto d’incontro tra le funzionalità centralizzate fornite dalle reti
strutturate client-server e l’uguaglianza dei nodi fornita dalle
classiche reti peer-to-peer non strutturate.
1.1.3.1 Esempi di reti P2P basate su modelli ibridi
Un esempio di modello ibrido è fornito da Spotify, un noto servizio
commerciale di streaming di musica. Esso utilizza un protocollo P2P
proprietario studiato appositamente per lo streaming musicale.
Inoltre, si basa su una rete P2P non strutturata in cui non vi sono
nodi privilegiati o supernodi. Tuttavia, si utilizzano tracker lato server
per localizzare gli altri utenti che possiedono la musica che si vuole
ascoltare. Infatti, per questo motivo, Spotify può essere considerato
un modello ibrido.
1.2 CACHING IN RETI P2P
Utilizzare strategie di caching di risorse nell’ambito delle reti P2P
analizzate nei paragrafi precedenti può avere un effetto positivo
sull’uso della rete e, conseguentemente, una riduzione dei costi da
parte dell’Internet Service Provider (ISP).

9
Nei seguenti paragrafi si analizzano nel dettaglio alcune strategie
allo stato dell’arte per quanto riguarda reti P2P, riferendosi in
particolare a reti gestite (1.2.1) o meno (1.2.2) da un ISP.
1.2.1 CACHING IN RETI P2P GESTITE DA UN ISP
Nell’articolo [CAR10], gli autori Y. Carlinet, H. Debar, Y. Gourhant e
L. Mé analizzano le performance di caching in reti P2P e studiano
come esse siano affette da una serie di fattori, tra cui il tipo di
algoritmo di cache scelto, ma anche dalle proprietà dell’overlay, dai
contenuti P2P e dalla location della cache stessa. In particolare, gli
autori di questo articolo hanno analizzato il traffico P2P sulla rete di
France Network, concentrandosi su quello prodotto dall’applicazione
di file-sharing più popolare in Francia, cioè eDonkey, una rete P2P
non strutturata e decentralizzata.
In eDonkey, i files sono identificati da un numero hash univoco e
sono divisi in parti più piccole, chiamate chunk. In questo modo i
peer possono scaricare un file da più fonti. Inoltre, è possibile
iniziare a caricare chunk prima di aver completato il download
dell’intero file, consentendo una velocizzazione della distribuzione di
file molto grandi. I chunk sono a loro volta troppo grossi per rientrare
in un solo messaggio eDonkey e vengono perciò suddivisi in parti di
10240 byte ciascuna quando vengono trasmesse da un nodo ad un
altro. Questo comportamento rende ulteriormente complesso il
caching di file.
L’analisi degli autori si è poi spostata su due differenti tipi di cache,
le cache attive e quelle passive.
In particolare, una cache si dice attiva quando essa scarica
completamente i file per cui c’è almeno una parte richiesta. In
questo caso non si ha tipicamente un risparmio in termini di banda
in quanto si scarica un intero file anche se ne è stata richiesta
solamente una parte. Bensì, si può osservare un maggiore hit ratio e
quindi un download più veloce da parte dei clienti.
Viceversa, una cache si dice passiva se non comporta download
addizionali rispetto ai casi in cui non vi fosse caching. La banda
salvata risulta quindi uguale ai dati offerti dalla cache ai clienti.
Nell’articolo in esame, si noti che una richiesta duplicata di

10
download di un file non comporta necessariamente il fatto che il file
sia risiedente in cache, infatti il file potrebbe essere stato rimosso
dalla cache nell’intervallo di tempo intercorso tra le due richieste.
Dunque, le cache attive non risparmiano banda ma consentono
download più veloci per l’utente finale. Per questo motivo, un
operatore ISP potrebbe scegliere questo tipo di cache per offrire
migliori servizi applicativi ai propri clienti. Tuttavia, la scelta di quale
tipo di cache sviluppare deve essere ponderata anche su altri fattori,
quali, ad esempio, considerazioni di tipo economico. Infatti, per
alcuni ISP che forniscono collegamenti peer-to-peer attraverso
comunicazioni satellitari (ad esempio nei paesi emergenti o in aree
rurali) il costo della banda non ha un peso indifferente (può essere
infatti 50 volte maggiore di connessioni via cavo). In questi casi una
cache attiva è difficilmente sopportabile e si deve preferire una
soluzione di cache passiva, la quale consentirebbe grossi risparmi
sui costi.
Infine, in seguito all’analisi dei dati raccolti, gli autori di [CAR10]
hanno potuto affermare che le performance di una cache in reti P2P
sono influenzate dai seguenti fattori:
 le caratteristiche dell’overlay e la specifica distribuzione della
popolarità dei file;
 le proprietà della cache: grandezza, politica di rimpiazzamento
e rate di download della cache per quanto riguarda la cache
attiva;
 il comportamento dei clienti: dato che essi possono scaricare
non completamente un file, la popolarità di un file non fornisce
abbastanza informazioni sul traffico di downstream;
 il numero di clienti: ovviamente la cache è più utile se serve un
numero elevato di clienti, poiché in questo caso è più probabile
che il traffico sia ridondante.
In ulteriori due articoli intitolati [HEF10] e [HEF08], gli autori
Mohamed Hefeeda e Behrooz Noorizadeh analizzano il potenziale
di un proxy caching cooperativo in reti P2P con lo scopo di ridurre
il carico imposto sugli ISP. In particolare, sono proposti due modelli
di caching cooperativo di traffico P2P. Il primo abilita la

11
cooperazione tra cache che appartengono a differenti Autonomous
System (AS), mentre il secondo considera la cooperazione tra
cache sviluppate nello stesso AS.
Per quanto riguarda il primo modello, si ipotizza lo sviluppo di cache
vicino ai gateway router dei diversi AS, come schematizzato in
Figura 4.
Figura 4. Primo modello proposto: cooperazione fra cache in differenti AS.
Per avere il massimo vantaggio possibile dallo sviluppo delle cache
e per non dover modificare il codice sorgente del software del client
P2P, le cache dovrebbero essere trasparenti, in analogia al
comportamento dei sistemi di caching web in cui i router individuano
le richieste HTTP e le dirottano verso la cache web. In aggiunta, le
cache sviluppate in differenti AS cooperano fra loro per servire
richieste di clienti nelle loro reti. Le cache cooperanti tra loro
formano un cosiddetto cache group. La cooperazione di un cache
group funziona nel seguente modo: quando una cache riceve una
richiesta per un oggetto che non è memorizzato localmente, per
prima cosa cerca se le altre cache appartenenti al proprio gruppo
abbiano l’oggetto richiesto. Nel caso in cui qualcuno abbia l’oggetto,
esso è servito direttamente al client richiedente. Altrimenti, la

12
richiesta è inoltrata a fonti esterne. Inoltre, il processo di ricerca di
una risorsa all’interno delle cache del gruppo potrebbe essere
implementato in modi diversi. Nel caso in esame, si è scelto di
preferire una soluzione basata su una piccola modifica del protocollo
ICP (Internet Cache Protocol) piuttosto che l’utilizzo di una directory
centralizzata, in quanto costituirebbe un singolo punto di fallimento
per l’intero sitema di caching.
Il secondo modello di cooperazione proposto nei paper [HEF10] e
[HEF08] consiste nello sviluppo di cache all’interno dello stesso AS,
come schematizzato nella Figura 5.
Figura 5. Secondo modello proposto: cooperazione tra cache nello stesso grande
ISP.
Questo modello si rivela adatto a larghi ISP con molteplici punti di
accesso e di uscita. Infatti, la rete di ogni ISP è composta da diversi
Points of Presence (POP) a cui sono collegati connessioni inter-ISP.
Queste connessioni costituiscono il collo di bottiglia di Internet e
spesso sono molto costose in quanto gli operatori si pagano gli uni
gli altri per il trasporto del traffico attraverso le proprie reti. È quindi
evidente che un’ottimizzazione del traffico in uscita dalla rete di un
ISP può comportare un notevole guadagno per l’operatore stesso.
Gli autori hanno inoltre notato che la cooperazione delle cache
appartenenti allo stesso AS è di più facile implementazione nella

13
pratica rispetto al caso di cache appartenenti ad AS diversi. Questo
perché nel primo caso tutte le cache possono essere gestite da una
singola entità, mentre nel secondo caso ne sono coinvolte diverse.
Inoltre, nel secondo caso possono essere coinvolti problemi politici e
legali.
Gli autori hanno poi condotto uno studio di misurazione sulla rete di
file-sharing Gnutella per raccogliere e analizzare il traffico P2P. In
particolare, dalla versione 0.6 Gnutella ha due tipi di nodi (come già
introdotto nel paragrafo 1.1.1.1): gli ultrapeer, caratterizzati da
un’alta banda e lunghi periodi di connessione, e i nodi foglia, che
sono nodi ordinari connessi solamente agli ultrapeer. I nodi si
scambiano diversi tipi di messaggi tra cui PING, PONG, QUERY e
QUERYHIT. Gli autori hanno quindi deciso di modificare un
popolare client Gnutella, Limeware, per funzionare come nodo di
misurazione. In particolare, il nodo è stato configurato come un
ultrapeer in grado di registrare passivamente il contenuto dei
messaggi di QUERY e QUERYHIT che lo attraversavano. Dopo otto
mesi di misurazioni, gli autori sono giunti a interessanti
considerazioni su un aspetto molto importante nel caching del
traffico P2P, la popolarità di un oggetto. In particolare, hanno
confermato che la popolarità di un oggetto è di tipo flattened head,
come graficato nella Figura 6, la quale mostra la popolarità di un
oggetto in un AS d’esempio.
Inoltre, la Figura 6 mostra come una distribuzione di tipo Zipf
sovrastimerebbe la popolarità di un oggetto nella parte iniziale della
curva, proprio nel punto più importante per il caching. Invece, la
popolarità dei file potrebbe essere modellata in maniera più accurata
da una forma generalizzata delle distribuzioni Zipf chiamata
Mandelbrot-Zipf (MZipf). La distribuzione Mandelbrot-Zipf definisce
la probabilità di accedere ad un oggetto di rank i su N oggetti
disponibili come segue:
dove
∑
, con α che è il fattore di asimmetria e
q≥0 è un parametro chiamato fattore plateau, poiché influenza la
forma della curva del plateau nella parte destra della distribuzione.

14
Figura 6. La popolarità delle risorse nei sistemi P2P è modellata in modo più preciso
da una distribuzione Mandelbrot-Zipf.
Questa distribuzione è utilizzata anche nell’analisi dei dati di
[GAO11] e [CAR10], in quanto considerata un modello affidabile per
la popolarità degli oggetti in sistemi P2P.
Gli autori di [HEF10] e [HEF08], per dimostrare la necessità di
cooperazione tra le cache, hanno poi simulato il caso in cui siano
presenti cache indipendenti in ogni AS preso in esame. In questo
caso, la cache utilizza un algoritmo offline ottimale denominato
iOPT. iOPT analizza offline l’intera rete e memorizza i file più
popolari che permettono di riempire la cache. Attraverso diverse
simulazioni, gli autori hanno potuto accertare che una singola cache
non è sufficientemente estesa da memorizzare abbastanza oggetti
popolari da raggiungere un alto Byte Hit Rate (BHR). È quindi
evidente la necessità di più cache cooperanti fra loro.
In particolare, nei paper in esame vengono analizzare le
performance di due realistiche politiche di sostituzione: la
cooperative Least Recently Used (cLRU) e la cooperative Least
Frequently Used (cLFU). La cLRU (e similarmente la cLFU)
lavorano nel modo seguente: quando una risorsa non è presente
nella cache locale ma viene individuata in un’altra cache dello
stesso gruppo, la risorsa viene scaricata da tale cache ma non viene
memorizzata in locale. In questo modo si mantiene una sola copia
cache per ogni gruppo. L’aggiornamento della cache avviene

15
solamente nel caso in cui si abbia una risposta da parte di un client
locale. In questo modo, tutte le cache del gruppo cooperano per
implementare una politica LRU attraverso il gruppo.
Figura 7. Confronto fra sistemi di caching indipendenti e cooperativi per quanto
riguarda cache in AS diversi (a sinistra) e nello stesso AS (a destra).
I grafici a in Figura 7 mostrano il miglioramento del BHR nel caso di
cache risiedenti in AS differenti e nello stresso AS. Inoltre, è
mostrata la differenza tra politiche di caching indipendenti (iLFU) e
cooperanti (cLFU). Questi grafici mostrano inoltre come si possa
avere un netto vantaggio in termini di BHR dall’uso di cache
cooperative. Infine, i risultati proposti dagli autori mostrano che
l’overhead imposto dalla cooperazione delle cache è trascurabile
(intendendo come overhead il numero di byte addizionali trasmessi
a seguito del trasferimento di un file richiesto): meno dello 0,003
percento del traffico totale.
1.2.2 CACHING IN RETI P2P SENZA ISP
Invece, per quanto riguarda le reti senza ISP, G. Gao, R. Li, W. Xiao
e Z. Xu indagano [GAO11] sulle tecniche per realizzare un caching
distribuito efficiente, prevalentemente in reti di tipo strutturato. In
particolare, vengono prese in esame strategie di posizionamento
della cache e strategie di rimpiazzo in sistemi di tipo strutturato che
utilizzino Distributed Hash Table (DHT).
Per quanto riguarda le strategie di posizionamento della cache,
vengono prese in considerazione le seguenti soluzioni:

16
 nelle strategie All Peers (AP) il sistema seleziona tutti i nodi
attraversati dal percorso di ritorno della query di richiesta di una
risorsa e memorizza l’oggetto richiesto in ognuno di essi;
 nelle strategie Interval Peers (IP) il sistema seleziona solamente
un nodo ogni N in cui mantenere una copia dell’oggetto richiesto;
 nelle strategie Probability-based Sub-network Peer (PSP) ogni
nodo in una sottorete prova a mantenere in cache gli oggetti in
modo da supportare potenziali query dagli altri peer della
sottorete. In questo routing gerarchico, una query è eseguita
prima nella sottorete. Se è trovata una corrispondenza nella
cache interna della sottorete, la risorsa viene direttamente
scaricata, altrimenti la query viene instradata nei layer di più alto
livello sino alla DHT globale;
 nelle strategie Last Sub-network Peer (LSP) viene sempre
selezionato l’ultimo peer lungo il percorso della query come nodo
su cui mantenere copia cache della risorsa richiesta. Dato che
nel routing con DHT, all’interno di una sottorete, query per lo
stesso oggetto avranno sempre lo stesso ultimo nodo, ci si
aspetta un alto hit ratio per la cache.
In aggiunta, si deve sviluppare un secondo algoritmo: quello per la
gestione della politica di ricambio della cache. Infatti, nel
momento in cui si decide di mantenere una copia di una risorsa si
deve controllare prima lo spazio disponibile nella cache stessa. Nel
caso in cui non vi sia più spazio sufficiente, si deve scegliere se e
quale risorsa eliminare per lasciare posto alla nuova. Ci sono diversi
algoritmi di rimpiazzo:
 Least Recently Used (LRU): viene espulso l’oggetto usato meno
di recente nella cache;
 Least Frequently Used (LFU): si mantengono in cache gli oggetti
usati più frequentemente;
 Most Recently Used (MRU): viene rimpiazzato l’oggetto
acceduto più frequentemente con lo scopo di mantenere in
cache il maggior numero di oggetti distinti, anche con poco
spazio a disposizione;
 Greedy-Dual Request (GDR): è basato sull’algoritmo Greedy-
Dual, originariamente utilizzato per le pagine in cache o in

17
memoria. In particolare, GDR consente di attribuire più peso ai
file moderatamente o poco popolari (evitando di mantenere in
cache troppi file popolari) e allo stesso tempo aiuta a mantenere
le risorse popolari al di sopra di una determinata soglia,
sufficiente a soddisfare le query;
 Probability-based Most Recently Used (PMRU): esso concorda
con il MRU sulla necessità di non avere in memoria troppe copie
degli oggetti popolari. Tuttavia, per evitare di rimuovere troppi
duplicati, la scelta di espellere o meno un file si calcola sulla
radice quadrata della popolarità.
Infine, si valuta la necessità di introdurre una pulizia proattiva delle
copie cache sovrabbondanti e non necessarie. Infatti, si è calcolato
che il 5% dei file più popolari occupano il 49% dello spazio di cache
con l’algoritmo LFU, mentre il valore di hit rate della cache aumenta
solo del 27%.
In un secondo articolo [WAN04], gli autori C. Wang, L. Xiao, Y. Liu e
P. Zheng propongono un nuovo protocollo di cache in reti P2P non
strutturate Gnutella-like. Gli autori partono dall’analisi di un
meccanismo di caching ad uniform index in cui il risultato della query
di ricerca di una risorsa è mantenuto in cache in tutti i peer lungo il
percorso inverso della query. In questo modo, la query su altri peer
può essere soddisfatta dal risultato mantenuto in cache nelle
vicinanze. In estensione a questo meccanismo, gli autori dell’articolo
propongono un proprio protocollo chiamato Distributed Caching and
Adaptive Search (DiCAS). Nelle reti Gnutella che sfruttano questo
meccanismo, tutti i peer sono logicamente divisi in diversi layer, con
il vincolo che tutti i nodi nello stesso layer hanno lo stesso ID di
gruppo. Il flooding della query di ricerca è quindi ristretto solamente
al layer con ID di gruppo corrispondente.
In particolare, per localizzare un file in una rete Gnutella classica, un
nodo sorgente invia in flooding una query a tutti i suoi diretti vicini.
Quando un peer riceve una query, esso controlla in un indice locale
contenente i propri file se è in possesso o meno della risorsa
richiesta. In caso positivo, invia una risposta a ritroso lungo il
percorso della query, altrimenti continua il broadcast. Ad esempio,

18
nella Figura 8 è schematizzato il flooding di una query di ricerca e il
successivo trasferimento del file richiesto.
Figura 8. Protocollo di ricerca e recupero di un file in una rete Gnutella
Nel protocollo DiCAS, in aggiunta all’indice locale dei file locali, ogni
peer conserva un indice delle risposte il quale mantiene in cache i
risultati delle query che fluiscono attraverso di esso. Ogni oggetto
nell’indice delle risposte è costituito dal nome del file e indirizzo IP
del nodo che ha risposto e in cui la risorsa è localizzata. Quindi,
quando un peer riceve una query da un vicino, controlla sia l’indice
locale sia l’indice delle risposte.
Inoltre, invece di mantenere una copia delle risposte in ogni nodo
lungo il percorso, DiCAS permette di effettuare caching solo in
alcuni nodi selezionati. La chiave dell’algoritmo risiede
nell’individuare in quali nodi mantenere o meno una copia cache.
In particolare, quando un peer aderisce alla rete, ad esso viene
assegnato un numero casuale compreso tra 0 e M-1 corrispondente
all’ID del gruppo. Inoltre, un algoritmo uniforme di hash è utilizzato
per tradurre la stringa del nome del file in un valore hash. A questo
punto, si stabilisce che un nodo deve mantenere una copia cache se

19
il proprio valore di ID del gruppo è uguale all’hash calcolato sul
nome del file contenuto nella query modulo M.

Ad esempio, come schematizzato nella Figura 9,
se M=2 tutti i peer della rete vengono separati in soli due gruppi.
Figura 9. Strategia di caching di DiCAS
Supponendo che il risultato del modulo del valore risultante
dall’hash della stringa del nome del file equivalga a 1, solo i peer
appartenenti al gruppo con ID uguale a 1 manterranno in cache la
risposta.
In un ultimo articolo [ZHU11] riguardante reti P2P senza ISP, gli
autori X. Zhuo, Q. Li, G. Cao, Y. Dai, B. Szymanski e T. La Porta
descrivono come il caching cooperativo sia una tecnica comune per
migliorare le performance di accesso ai dati nelle reti tolleranti ai
ritardi (Delay Tolerant Network – DTN).
In particolare, nelle reti DTN i nodi mobili sono connessi tra loro
attraverso l’uso di collegamenti opportunistici. A causa della mobilità
impredicibile dei nodi, non ci sono connessioni end-to-end tra due
peer mobili e questo impatta drasticamente sulle performance di
accesso ai dati. Inoltre, le tecniche di caching cooperativo
frequentemente utilizzate nelle reti via cavo e wireless non possono
essere applicate alle DTN a causa della topologia instabile e alla
durata del contatto limitata. Ad esempio, a causa della mobilità dei
nodi e a causa della topologia instabile, una risorsa presente in un

20
nodo di cache potrebbe non essere momentaneamente
raggiungibile. In aggiunta, se il tempo di connessione di un nodo è
tipicamente corto a causa dell’alta mobilità, troppi dati di cache
memorizzati nello stesso peer renderebbero difficile l’invio completo
della risorsa richiesta, producendo inoltre uno spreco di risorse
d’archiviazione. Per questi motivi, capire dove mantenere la cache e
quanto grande essa debba essere è considerata una sfida nelle reti
DTN.
Per ovviare all’intrinseca instabilità della topologia delle reti DTN, gli
autori di [ZHU11] hanno sfruttato delle relazioni relativamente stabili,
quelle sociali. Infatti, dato che nodi appartenenti alla stessa
comunità hanno una probabilità più alta di incontrarsi, è più facile
che un nodo ottenga risorse dagli appartenenti alla stessa comunità
piuttosto che da esterni. Appare quindi sensato progettare un
meccanismo di caching tra i nodi appartenenti alla stessa comunità.
Inoltre, gli autori sostengono che, a causa della limitata durata delle
connessioni, più pacchetti sono immagazzinati in un singolo nodo,
più l’efficienza della cache diminuisce. Per questo motivo si deve
valutare attentamente quanti dati memorizzare nella cache in ogni
nodo.
Gli autori di [ZHU11] passano poi ad introdurre nel dettaglio il
modello basato sulla rete sociale. In particolare considerano due
concetti chiave: la comunità e la centralità.
La comunità è considerata come un’unione coerente: i nodi
appartenenti alla stessa comunità tendono ad avere contatti regolari
e frequenti. Perciò, si sfrutta questo comportamento per sviluppare
un caching cooperativo, che abilita la condivisione di dati all’interno
della comunità.
La centralità, invece, misura il potere sociale di un nodo basandosi
su come esso sia connesso alla rete. Dunque, un nodo con alta
centralità è più importante nella sua comunità. Inoltre, ci sono tre
tipiche metriche di centralità:
1. degree centrality: rappresenta il numero di legami che un nodo
ha con gli altri pari;
2. closeness centrality: rappresenta la distanza tra un nodo e gli
altri vicini;

21
3. betweenness centrality: rappresenta la misura di come i nodi si
trovino sui percorsi più brevi che li collegano agli altri nodi.
Infine, si propone un protocollo di caching denominato Duration
Aware Caching (DAC). Questo protocollo non si limita a tenere
conto solamente della centralità di un nodo per decidere su quale
peer mantenere la cache. Infatti, come già accennato, mantenere
troppi pacchetti nello stesso nodo provocherebbe una diminuzione
delle performance a seguito della scarsa durata delle connessioni
intrinseca alle reti DTN. Per questo motivo si preferisce distribuire i
pacchetti in più cache, mantenendo sempre una proporzionalità in
base alla centralità.
Figura 10. L’impatto della limitazione della durata di contatto sul caching. Il numero
scritto a lato della doppia freccia indica il numero di pacchetti che possono
essere trasmessi durante il contatto.
Ad esempio, come si può vedere nello scenario di Figura 10, una
cache troppo grande rispetto al massimo numero di pacchetti che
possono essere trasmessi durante un contatto si rivela inutile. È
dunque preferibile utilizzare più cache di dimensioni ridotte, ma che
possano trasferire i dati durante il periodo di una propria
connessione.
1.3 CONSIDERAZIONI CONCLUSIVE
Dalle analisi dei paragrafi precedenti, risulta evidente come, in un
sistema P2P moderno, sia necessario prevedere sistemi di caching
delle risorse, sia per migliorare la qualità del servizio offerto ai
clienti, sia per ridurre il traffico e, conseguentemente, i costi a carico
dell’ISP. Inoltre, si è evidenziata la necessità di creare un sistema
costituito da più cache cooperanti fra loro, le quali possono garantire

22
maggiori performance rispetto a un sistema formato da cache
indipendenti tra loro, specialmente in scenari molto estesi. Infine,
sono state analizzate diverse politiche di piazzamento e gestione
della cache, le quali saranno nuovamente prese in considerazione
durante le fasi progettuali del Capitolo 3.

23
CAP.2
MIDDLEWARE RAMP
In seguito alla sempre maggiore diffusione di dispositivi elettronici
molto eterogenei fra loro, ma contraddistinti dalla crescente capacità
di creare e condividere contenuti multimediali di diverso genere, si è
resa indispensabile la presenza di un middleware di gestione che
potesse guidare le esigenze delle diverse applicazioni a runtime. Da
questa esigenza nasce RAMP (Real Ad hoc Multihop Peer-to-
peer) [RAMP], un middleware implementato su reti dinamiche
wireless esistenti ed eterogenee, le quali sfruttano, ad esempio, sia
collegamenti di tipo IEEE 802.11 sia Bluetooth. In letteratura, queste
reti vengono chiamate reti spontanee (Spontaneous Network - SN).
Nei prossimi paragrafi, verranno analizzate approfonditamente
questo tipo di reti (Paragrafo 2.1). Saranno poi esaminati diversi
scenari applicativi (Paragrafo 2.2) e le linee guida nello sviluppo di
un middleware per la gestione di reti SN (Paragrafo 2.3), prima di
analizzare l’architettura base di RAMP (Paragrafo 2.4) e successive
estensioni (Paragrafo 2.5). Infine, sarà studiata la possibilità di
condividere automaticamente contenuti basandosi sulle identità e
sulle relazioni sociali (Paragrafo 2.6).
2.1 RETI SPONTANEE
Come descritto in [BEL12], con il termine SN si indicano quelle reti
dinamiche e collaborative che coinvolgono interfacce wireless
eterogenee e percorsi multi-hop relativamente brevi. Inoltre, le SN
derivano dall’interazione improvvisata di dispositivi sia mobili sia
fissi, tipicamente amministrati da un piccolo numero di utenti
interagenti socialmente.
Oggigiorno, le SN stanno emergendo come un sottocampo di
ricerca con caratteristiche specifiche, differenti dalle aree adiacenti
delle Wireless Mesh Network (WMN) e delle Reti Opportunistiche
(Opportunistic Network – ON), le quali sono un’evoluzione della
vecchia e più generale area chiamata Mobile Ad hoc Network
(MANET). Queste reti sono confrontate brevemente nella Tabella 1.
In particolare, viene proposta una suddivisione di queste aree di

24
ricerca in base a tre caratteristiche fondamentali: la scalabilità della
rete, la qualità della connessione e l’affidabilità della
comunicazione (altri aspetti con un impatto secondario sono la
dinamicità della connessione, la mobilità dei nodi e l’eterogeneità dei
ruoli).
WMN SN ON
Scalabilità
(numero di
nodi)
> 1.000 Da 10 a 100 Non obiettivo
primario
Affidabilità Ad ogni nodo Ad ogni nodo e
pacchetto,
best effort
Ad ogni
pacchetto
Qualità Obiettivo
primario
Best effort Non un obiettivo
primario
Dinamicità Limitata, non un
obiettivo primario
Media Alta
Mobilità dei
nodi
Limitata, solo
client
Media, anche di
adesione ad
gruppo sociale
Alta, obiettivo
primario
Eterogeneità
dei ruoli
Client, router,
accesso ad
Internet
Peer Peer
Tabella 1. Una breve comparazione tra le reti WMN, SN e ON.
Per quanto riguarda le WMN, questo tipo di reti si focalizza sulla
scalabilità e sulla qualità. Infatti, un tipico scenario può essere
formato da svariati nodi, addirittura migliaia. In questa situazione
una degli obiettivi cruciali è garantire sufficiente qualità ai nodi.
Inoltre, si tendono ad identificare dei ruoli dei nodi, come ad
esempio nodi clienti che accedono ad internet e che possono
muoversi e nodi intermedi che tendono a rimanere fissi.
Al contrario, le ON sottolineano gli aspetti relativi all’inaffidabilità dei
percorsi dovuta alla mobilità dei nodi. A causa della probabile
momentanea incapacità di raggiungere un nodo desiderato, gli sforzi
di ricerca si concentrano soprattutto nel progettare algoritmi euristici

25
atti a massimizzare la probabilità che un pacchetto in movimento si
avvicini alla destinazione. Comunque, la scalabilità e la qualità non
sono obiettivi fondamentali, bensì lo è la consegna del singolo
pacchetto.
Invece, per quanto riguarda le SN, lo scopo principale è quello di
offrire facilmente connessioni fra utenti che interagiscono
socialmente. Da un lato, le SN possono essere viste come una
versione semplificata e pratica delle precedentemente citate aree di
ricerca. Infatti, i requisiti di scalabilità e qualità richiesti sono di solito
meno restrittivi rispetto alle WMN: le SN connettono tipicamente
piccoli gruppi di persone nelle vicinanze, offrendo, ricercando e
invocando servizi P2P. Questo semplifica molte operazioni (ad
esempio la ricerca può essere effettuata per flooding). In aggiunta,
la mobilità e la dinamicità sono inferiori rispetto alle ON, rendendo
spesso superflua l’onerosa replicazione dei dati delle ON. Dall’altro
lato, le SN fanno sorgere nuove sfide tecnologiche poiché mirano a
sfruttare dispositivi commerciali eterogenei fra loro, come
smartphone e laptop, i quali hanno hardware molto diversi e
capacità di comunicazioni differenti (come UMTS, IEEE 802.11 e
Bluetooth). Allo stesso tempo, i ruoli dei nodi tendono a variare
velocemente, ad esempio offrendo o richiedendo un determinato
servizio, collaborando o meno con la SN, magari per risparmiare
batteria nei dispositivi mobili.
Recenti ricerche hanno proposto diverse forme di cooperazione tra i
nodi considerando ambienti di sviluppo specifici, spesso ottenuti
modificando in maniera non standard i protocolli di layer-2. Al
contrario, le soluzioni adottate in RAMP ed analizzate nei paragrafi
seguenti non intendono imporre modifiche ai livelli bassi o al sistema
operativo, le quali comporterebbero modiche agli standard.
2.2 SCENARI APPLICATIVI
Per chiarire le esigenze più comuni e specifiche alle applicazioni
delle reti SN, sono di seguito proposti tre scenari applicativi
differenti: la condivisione di file in un’aula di studenti, una
conferenza audio/video durante un meeting di progetto e la
consegna di messaggi critici in una situazione di emergenza.

26
2.2.1 FILE SHARING
Nel primo scenario, un gruppo di studenti si trova in un’aula e
intende condividere gli appunti della lezione in sottogruppi di amici,
creati in maniera improvvisata da possibili partecipanti risiedenti
simultaneamente in diverse sottoreti. Per esempio, il nodo A nella
Figura 11a vuole accedere ai file condivisi dal nodo E utilizzando il
nodo C come gateway tra la PAN Bluetooth e la rete ad-hoc WiFi
(modalità IBSS). In questo scenario, è ragionevole pensare che lo
scopo principale sia il download del file desiderato, possibilmente
con meno latenza possibile e con un impatto minimo sui nodi
intermediari. In particolare, per ridurre il sovraccarico sui
partecipanti, sembra ragionevole usare pacchetti con priorità e
affidabilità regolare (in caso di insuccesso nel trasferimento di un
file, lo studente stesso potrebbe prendersi carico del rinvio esplicito
della richiesta degli appunti).
2.2.2 VIDEOCONFERENZE
Nel secondo scenario, un gruppo di ricercatori partecipano ad un
meeting di un giorno su progetto in un aeroporto. I ricercatori
vengono divisi i sottogruppi alloggiati in differenti stanze, ma
possono monitorare l’attività degli altri gruppi mediante
videoconferenze instradate attraverso percorsi multi-hop che
comprendono collegamenti ad hoc single-hop. Per esempio, il nodo
A in Figura 11b invia uno streaming audio/video al nodo D
attraverso il nodo C. In questo caso, lo scopo principale potrebbe
essere quello di mantenere vivo lo streaming, pur degradandone la
qualità, anche a seguito di cambiamenti parziali nella topologia della
rete. Infatti, in seguito ad un possibile cambiamento dinamico della
morfologia della rete dovuto alla dinamicità intrinseca ad essa, si
può tollerare la perdita di qualche pacchetto e la conseguente
perdita di qualità dello streaming, ma si vuole mantenere viva la
teleconferenza entro accettabili limiti di qualità. Ad esempio, se il
nodo C dovesse lasciare la SN, lo streaming dovrebbe essere
dinamicamente migrato attraverso il percorso che comprende i nodi
B, F ed E, anche sopportando il costo di overhead addizionali per il
calcolo del percorso alternativo.

27

Figura 11. Esempi di reti spontanee con diverse esigenze: (a) condivisione di file in
un’aula, (b) conferenza audio/video durante un meeting di progetto e (c)
consegna di messaggi critici in situazioni di emergenza.

28
2.2.3 CONSEGNA DI MESSAGGI CRITICI
Nel terzo scenario, i membri di un team di emergenza devono
potersi scambiare dei messaggi critici, ma potrebbero non esserci
sempre collegamenti disponibili tra il mittente e il destinatario. I
messaggi devo inoltre poter essere gestiti in maniera opportunistica
ed essere avvicinati al nodo destinazione non appena un
collegamento diventi disponibile. Infine, in caso di distruzione
improvvisa di un collegamento, gli intermediari dovrebbero
mantenere localmente il pacchetto fino a quando non possa essere
spedito successivamente, ovviamente pagando un costo
addizionale sulla memoria locale. Questa situazione risulta molto
simile a quella delle DTN, già descritte nel Paragrafo 1.2.2 e in
[ZHU11]. Ad esempio, il nodo A in Figura 1c potrebbe voler inviare
un messaggio critico al nodo G, anche se al momento non ci sono
collegamenti disponibili. Il nodo B potrebbe servire come nodo
mobile accettando il messaggio da A finché è ad esso connesso ed
inoltrandolo al destinatario non appena si connette al nodo E.
Questo scenario richiede la massima affidabilità e disponibilità,
anche al costo di aumentare lo spazio di memoria utilizzato e di
avere un maggiore overhead per la gestione dei percorsi.
2.3 LINEE GUIDA PER MIDDLEWARE SN
Nello sviluppo di soluzioni basate su middleware gestori di reti SN
(con particolare riferimento a RAMP), si dovrebbero seguire le
seguenti linee guida:
 gestione del routing effettuata dal middleware: l’instradamento
dei pacchetti dovrebbe avvenire a livello applicativo,
mantenendo l’indipendenza dal sistema operativo e dai layer
inferiori; tuttavia, si vuole ridurre al minimo l’overhead introdotto
dal middleware per la gestione dei collegamenti fra i vari nodi
che, a causa della natura delle reti SN, sono scoordinati e
intermittenti;
 approccio reattivo e mission-oriented: le applicazioni dovrebbero
trovare le risorse solamente quando richiesto; infatti, approcci
proattivi potrebbero risultare dispendiosi e inefficienti a causa
della natura delle reti SN;

29
 basso overhead: per mantenere il carico il più basso possibile, il
middleware dovrebbe essere in grado di riconfigurare i percorsi
dei pacchetti a runtime sfruttando solo una visibilità limitata e
coinvolgendo il minor numero di nodi possibile, sia nelle
vicinanze, sia sul percorso;
 comunicazioni stateless: considerando l’eterogeneità e la
dinamicità delle reti SN, i percorsi dei pacchetti dovrebbero
essere gestiti dinamicamente come una combinazione basata
sul middleware di singoli hop indipendenti e senza stato nei
protocolli più bassi dello stack.
2.4 ARCHITETTURA
Il middleware RAMP ha una architettura a due livelli (come
schematizzato nella Figura 12), uno più alto chiamato service layer
e uno inferiore denominato core layer. Il primo sostiene i servizi
P2P attraverso utilità di registrazione, pubblicizzazione e ricerca. Il
secondo fornisce astrazioni per la comunicazione end-to-end e
broadcast. In particolare, il Service Manager registra e pubblicizza
le applicazioni locali attraverso il servizio
registerLocalService. Invece, il componente Discovery ha lo
scopo di recuperare i servizi remoti (findRemoteServices)
determinando il percorso per raggiungerli in una maniera
completamente distribuita e solo quando richiesto.
Figura 12. Architettura a due livelli del middleware RAMP.

30
Protocolli di ricerca aggiuntivi possono essere facilmente integrati in
RAMP, addirittura a runtime, grazie alla sua architettura estendibile
basata su plug-in. Un esempio è descritto nel Paragrafo 2.5.1, dove
viene proposta l’integrazione con il protocollo di ricerca universal
plug and play (UPnP), attraverso l’incapsulazione trasparente nei
messaggi standard UPnP. Per quanto riguarda il core layer, il
modulo E2EComm offre primitive che permettono l’invio e la
ricezione di unicast multi-hop e di broadcast con un TTL limite
(receive, sendUnicast, sendBroadcast). Il Dispatcher
interagisce con i vicini per un routing collaborativo dei pacchetti
verso la loro destinazione, mentre l’Heartbeater ha lo scopo di
tenere traccia dei vicini distanti un singolo hop attraverso l’invio
periodico di broadcast UDP.
In aggiunta, RAMP sfrutta una struttura a plug-in per consentire
facilmente modifiche all’header o al payload dei pacchetti in ognuno
dei nodi attraversati. I componenti che intendono gestire il traffico
passante per il nodo devono implementare l’interfaccia Packet
Listener e registrarsi al Dispacher in un modo plug-in. Infatti, il
Packet Listener in Figura 12 rappresenta un componente generico
con il compito di ascoltare i pacchetti attraversanti il nodo. Ad
esempio, il componente Continuity Manager implementa
l’interfaccia Packet Listener e viene registrato al Dispatcher. Questo
componente ha il compito di gestire la temporanea indisponibilità di
un percorso, cercando percorsi alternativi e, in caso di impossibilità
a mandare il pacchetto, salvandolo localmente. In questo contesto,
gli sviluppatori di applicazioni possono sfruttare pienamente le API
offerte da RAMP nella creazione di nuove applicazioni, ma possono
anche utilizzare applicazioni preesistenti in maniera trasparente,
sfruttando proxy RAMP. Ad esempio, è disponibile un proxy RAMP
HTTP, attraverso cui è possibile incapsulare le richieste e le risposte
HTTP in pacchetti RAMP.
2.4.1 STRATEGIE DI GESTIONE DEI PACCHETTI
Infine, le applicazioni che utilizzano le API RAMP possono sfruttare
le strategie di gestione dei pacchetti descritte nei Paragrafi 2.4.1.1,

31
2.4.1.2 e 2.4.1.3. Inoltre, ne possono essere introdotte delle nuove
sempre utilizzando l’architettura a plug-in di RAMP.
2.4.1.1 Nonreliable Bulk Transfer
La strategia di gestione denominata Nonreliable Bulk Transfer (NBT)
è una strategia che intende ottenere le performance migliori e il
minor overhead possibile, anche a discapito di una bassa
affidabilità. Questa strategia è particolarmente adatta a scenari che
richiedono il trasferimento di massa di molti file, ma allo stesso
tempo si vuole ridurre l’ovehead sui nodi intermedi partecipanti alla
SN. Inoltre, si può tollerare il fallimento di un invio: in questo caso
sarà compito dell’utente riavviare manualmente la trasmissione. Lo
scenario appena descritto risulta quindi applicabile nel caso d’uso di
file sharing descritto nel Paragrafo 2.2.1.
Dunque, in caso che un’applicazione richieda una strategia NBT,
RAMP suddivide trasparentemente i pacchetti scambiati (come ad
esempio un file) in data chunk più piccoli e li invia dal mittente al
destinatario in maniera ordinata e concorrente. In Figura 13 è
riportata una comparazione di una comunicazione con e senza
NRBT.
Figura 13. Pacchettizzazione a livello middleware attuata da RAMP.
2.4.1.2 Reliable Packet Streaming
La strategia Reliable Packet Streaming (RPS) ha lo scopo di
mitigare gli effetti indesiderati provocati da una disconnessione,
anche attraverso un limitato sfruttamento di risorse addizionali da

32
parte dei partecipanti. Al contrario di NRBT, RPS funziona bene per
lo streaming dei pacchetti: essa abilita il re-rountig dinamico e
trasparente in caso di distruzione di un percorso, come chiaramente
schematizzato nella Figura 14. Un possibile scenario applicativo può
essere quello descritto nel Paragrafo 2.2.2, in cui si ipotizzava una
probabile videoconferenza durante un meeting di progetto.
Figura 14. Re-rountig dinamico e trasparente dei pacchetti ottenuto con RPS.
2.4.1.3 Highly Reliable Message Delivery
La strategia denominata Highly Reliable Message Delivery (HRMD)
mira ad ottenere la massima disponibilità di servizi tolleranti ai ritardi
(delay-tolerant). In particolare, quanto è impostata la strategia
HRMD e non vi sono collegamenti con il destinatario, RAMP
immagazzina momentaneamente i pacchetti sui nodi intermediari
dove al momento non ci sono possibilità di trasmissioni single-hop.
In questo modo, si rende possibile l’invio dei pacchetti in un secondo
momento, magari quando la topologia della rete è cambiata e si è in
grado di raggiungere la destinazione, come esemplificato in Figura
15. Questa strategia è quindi adatta per scenari di scambio di
messaggi di emergenza, come quella analizzata nel Paragrafo
2.2.3.

33
Figura 15. Esempio di strategia HRMD basata su Stroe, Carry and Forward (SCF).
2.5 ESTENSIONI DEL MIDDLEWARE RAMP
Le soluzioni proposte dal middleware RAMP analizzate fino ad ora
si proponevano di risolvere scenari di utilizzo limitati a reti SN locali,
dove i dispositivi erano tipicamente in visibilità diretta. Queste reti
vengono chiamate isole domotiche (domotic island), in quanto
spesso risultano essere piccole LAN private o reti ad hoc composte
da dispositivi dello stesso proprietario, tipicamente connesse ad
Internet attraverso un modem ADSL o uno smartphone abilitato
all’UMTS. In questo scenario, si vorrebbero introdurre soluzioni che
permettessero di scoprire, accedere e controllare nuovi dispositivi
e/o servizi risiedenti in isole domotiche differenti, perfino utilizzando
UPnP (un insieme di protocolli, ormai standard industriale, che
permette di scoprire nuovi dispositivi collegati alla rete e sfruttarne i
servizi). Da queste esigenze, sono nate due estensioni di RAMP
[BEL812]: Multi-hop UPnP Carrier (MUC – descritto nel Paragrafo
2.5.1) e Extended RAMP Network (ERN – Paragrafo 2.5.2).
2.5.1 MULTI-HOP UPNP CARRIER
L’estensione Multi-hop UPnP Carrier (MUC) permette la scoperta
dinamica e la comunicazione fra dispositivi e/o servizi UPnP a
distanza multi-hop come se fossero localizzati nella stessa

34
sottorete IP. Questa soluzione è compatibile con servizi UPnP
preesistenti, perciò si possono abilitare componenti UPnP già
sviluppati e ad una distanza multi-hop ad interagire tra loro in
maniera trasparente. Ciò è reso possibile dal MUC che si comporta
da proxy tra UPnP e RAMP, ad esempio incapsulando messaggi
multicast UPnP in un pacchetto broadcast RAMP, abilitandone il
trasporto multihp.
2.5.2 EXTENDED RAMP NETWORK
Il middleware RAMP supporta il dispatching di pacchetti attraverso
percorsi multi-hop solo se una istanza di RAMP è attiva in ogni
sottorete intermedia tra la sorgente e la destinazione. Invece, nodi
RAMP collocati in differenti SN non sono in grado di comunicare
anche se entrambi connessi ad Internet. La soluzione che sorpassa
questi limiti è Extended RAMP Network (ERN). Essa fornisce
l’opportunità di unire (federare) due SN distinte attraverso una
comunicazione P2P, supportando l’invio di pacchetti fra nodi RAMP
risiedenti in diverse posizioni di Internet. In particolare, nodi RAMP
con una connessione Internet diretta cooperano con nodi simili
appartenenti a diverse SN per effettuare il dispatch dei pacchetti ai
nodi senza una connessione diretta ad Internet.
Le linee guida della progettazione e dell’implementazione di ERN
sono state le seguenti:
1. dare un nome alle federazioni, differenziando le reti spontanee
disponibili attraverso un nome logico (ad esempio, “casa”,
“lavoro”, “amici”,…);
2. avere un controllo degli accessi basato sui ruoli, specificando un
insieme di utenti remoti che possono accedere ad una
determinata federazione (ad esempio, “Mario” può accedere
sempre a tutte le federazioni, mentre “Bob” può accedere solo ad
“amici” nelle prossime tre ore);
3. garantire una comunicazione P2P sicura ed efficiente, cifrando
ed autenticando i pacchetti inviati fra nodi RAMP comunicanti
attraverso Internet, senza l’aiuto si terze parti.
Inoltre, i componenti costituenti ERN sono i seguenti (un esempio di
topologia è raffigurato in Figura 16):

35
 RAMP Internet Node (RIN): un nodo RAMP con connettività
diretta ad Internet e che distribuisce pacchetti sia ad altri nodi
appartenenti alla stessa SN sia ad altri RIN remoti appartenenti a
SN differenti;
 ERN Manager: gestisce una o più federazioni, supportando la
procedura di adesione dei RIN remoti e immagazzinando e
distribuendo la lista dei RIN appartenenti ad ogni federazione
gestita.
Infine, per quanto riguarda il problema della sicurezza, ogni RIN
sfrutta una chiave simmetrica chiamata ERN Shared Key (ESK)
per cifrare/autenticare e decifrare/verificare i pacchetti trasmessi da
o verso una SN differente. L’ERN Manager ha il compito di creare
differenti ESK per ogni federazione e fornirla ai RIN che gestisce.
Inoltre l’ERN manager rinnova periodicamente le credenziali dei
nodi appartenenti alla federazione.
Figura 16. Esempio di topologia di federazioni basate su ERN.
2.6 CONDIVISIONE BASATA SULLE RELAZIONI SOCIALI
Oggigiorno, gli utenti del mercato di massa sono soliti condividere
contenuti multimediali attraverso due metodologie molto diffuse:
servizi di cloud storage (come ad esempio Dropbox e Ubuntu One)
e servizi di Online Social Network (OSN), come ad esempuo
Facebook e Twitter. In entrambe le soluzioni sono presenti diversi
difetti, tra cui:

36
1. proprietà dei dati: durante la condivisione dei propri dati in uno
degli scenari appena descritti, gli utenti perdono il controllo dei
propri contenuti; possono inoltre insorgere problemi legali, in
quanto i dati potrebbero essere spostati su server in Paesi con
leggi diverse oppure i dati dell’utente potrebbero essere usati a
fini commerciali; infine, non si può essere sicuri dell’effettiva
rimozione dopo la cancellazione da parte dell’utente o dopo
l’eliminazione di un account;
2. disponibilità dei contenuti: i servizi lato server potrebbero
essere momentaneamente indisponibili anche nel caso in cui
l’utente sia connesso ad Internet, rendono inaccessibili i propri
dati;
3. limitazioni di spazio di archiviazione o banda: solitamente i
servizi gratuiti hanno limitazioni di banda e/o spazio di
archiviazione e per usufruire appieno del servizio è richiesto un
pagamento addizionale;
4. dati legati al provider dei servizi: gli utenti sono costretti a
sottoscriversi a servizi specifici; in caso si voglia migrare i propri
dati ad altri provider, si deve provvedere manualmente allo
spostamento dei propri contenuti, operazione dispersiva sia per
tempo che per banda utilizzata.
Per risolvere questi problemi, si è pensato [BEL13] di sfruttare le reti
SN e le loro federazioni per condividere ed accedere ai contenuti
generati dagli utenti, senza dover utilizzare provider di servizi di
terze parti. A questo scopo si è deciso di creare reti centrate
sull’identità sociale (User Centered Network – UCN) e loro unioni
automatiche. Infatti, si vogliono aggregare nodi appartenenti alla
stessa persona fisica, ma registrata con identità sociali differenti (ad
esempio Facebook e Twitter). Allo stesso tempo, si vuole consentire
ad altri utenti in relazione sociali con il possessore di determinati
contenuti di accedere automaticamente a questi dati, basandosi su
filtri che sfruttano “l’intensità” delle relazioni che intercorrono fra
queste due persone (ad esempio, amico di, parte di un gruppo,
conosce, segue, scrive post su, …).
Questo scenario, che può essere esemplificato dalla Figura 17, è
tipicamente caratterizzato da dispositivi localizzati in differenti reti IP

37
gestite in maniera decentralizzata e non coordinata. Tuttavia, si
vogliono far comunicare tra loro questi nodi appartenenti a spazi di
indirizzi IP eterogenei. Con questo scopo, si sfrutta il middleware
RAMP e le sue estensioni MUC ed ERN. In questo modo, si
possono unire reti SN in maniera automatica e scoprire servizi in reti
distanti muli-hop, come ad esempio scoprire servizi di file sharing
nelle UCN federate. Ad esempio, nel possibile scenario di Figura 17,
Alice accede ad un album di foto risiedente sul NAS di Cate
(un’amica) attraverso un servizio UPnP, mentre Cate esegue
l’upload di una propria foto sul NAS casalingo dal suo tablet
(connesso ad Internet attraverso connettività UMTS).
Figura 17. Esempio di UCN federate e possibili scenari d’uso.
Il modello architetturale del manager di UCN proposto in [BEL13] è
essenzialmente composto dai seguenti componenti software
(schema in Figura 18):
 Social Observer: ha il compito di associare diversi profili OSN
appartenenti alla stessa persona fisica (ad esempio, un account
di Facebook ed uno di Twitter appartenenti alla stessa persona);
inoltre, monitora periodicamente gli OSN di interesse e notifica il
Social Merger (vedere prossimo punto) in seguito a cambiamenti
di relazioni sociali;
 Social Merger: ha il compito sia di creare una UCN personale
sia di aggregare UCN relativi ad utenti diversi basandosi
dinamicamente sulle informazioni raccolte dal Social Observer;

38
 Access Manager: fornisce la capacità di filtrare l’accesso dei
contenuti (CF) e la scoperta di servizi (DF) in base a regole di
visibilità, che ha il compito di gestire e di far rispettare. In
particolare, implementa l’interfaccia PacketFilter per
monitorare trasversalmente pacchetti RAMP, bloccando quelli
che non soddisfano i requisiti.
Figura 18. Architettura del Manager UCN.
2.7 CONSIDERAZIONI CONCLUSIVE
Utilizzando il middleware RAMP si è quindi in grado di gestire
facilmente diversi scenari applicativi che comportino la scoperta e
l’utilizzo di servizi risiedenti in una o più reti SN, anche appartenenti
a sottoreti IP distinte, per SN disgiunte. È inoltre possibile gestire
l’accesso e la condivisione dei contenuti generati dagli utenti in
maniera automatica, basandosi sulle identità e sulle relazioni sociali.

39
CAP.3
GESTIONE DINAMICA DI USER-GENERATED CONTENT
IN RETI SPONTANEE
Alla luce dell’analisi dello stato dell’arte delle strategie di caching in
reti P2P del Capitolo 1 e alla luce dello studio del middleware RAMP
e delle sue estensioni del Capitolo 2, il lavoro svolto in questo
progetto di tesi verte sull’implementazione di un servizio che
permetta la gestione dinamica dei contenuti generati dall’utente in
reti spontanee, in particolare gestite da RAMP.
Nel Capitolo 3 viene presentato un nuovo sistema di gestione
dinamica di contenuti generati dall’utente con l’obiettivo di valutarne
un possibile ricollocamento, in modo da offrire all’utente un minor
consumo di banda e una minore latenza nella richiesta di un file. Il
capitolo parte dall’analisi del contesto preesistente nel middleware
RAMP e in seguito presenta i dettagli implementativi delle soluzioni
adottate.
3.1 ANALISI CONTESTO PREESISTENTE
Il middleware RAMP è costituito da diversi progetti Java ed Android.
Il progetto principale è il progetto Java denominato RAMP. In esso è
contenuta l’implementazione del package chiamato
it.unibo.deis.lia.ramp.core e di quello denominato
it.unibo.deis.lia.ramp.service, costituenti essenzialmente
i due layer architetturali analizzati nel Paragrafo 2.4. In particolare,
per quanto riguarda i servizi implementati, è presente un servizio
chiamato FileSharingService, il quale ha il compito di abilitare
e gestire un servizio di File Sharing dei file locali. Infatti, l’utente,
dopo aver abilitato questo servizio dall’interfaccia principale stile
JFrame (Figura 19) oppure dall’interfaccia Web dedicata (Figura
20), può condividere i propri contenuti precedentemente collocati in
una directory specifica (di default ./temp/fsService) con altri
utenti RAMP, sia sulla stessa rete spontanea multi-hop, sia su reti
spontanee distinte, purché connesse ad Internet attraverso un RIN o
un ERN Manager (come spiegato nel Paragrafo 2.5.2). Inoltre, è

40
presente anche un client che permette l’interazione con i servizi di
File Sharing, permettendo all’utente di ricercare i servizi attivi
raggiungibili, richiedere la lista dei file remoti disponibili e, a questo
punto, scaricare un file desiderato oppure effettuare l’upload di un
file locale. Questo client è implementato da una classe Java
chiamata FileSharingClient e la sua interfaccia grafica è
rappresentata in Figura 21.
Figura 19. Interfaccia grafica JFrame di RAMP.
Figura 20. Interfaccia grafica web di RAMP.

41
Figura 21. Interfaccia grafica del client di File Sharing di RAMP.
Per quanto riguarda la ricerca dei servizi di servizi di File Sharing
attivi su altri nodi RAMP, il client esegue una ricerca utilizzando l’API
findServices offerta dalla classe ServiceDiscovery,
implementazione del modulo Discovery descritto nel Paragrafo 2.4.
Invece, per quanto riguarda il protocollo di invio e ricezione dei
file, la classe FileSharingClient invia una richiesta al servizio
correntemente selezionato, utilizzando una classe denominata
FileSharingRequest. In essa, sono memorizzate solamente le
informazioni riguardanti il nome del file che si desidera
inviare/ricevere, il numero della porta su cui il client si aspetta di
ricevere il file (in caso di download) e un boolean che ha lo scopo di
contrassegnare la richiesta come una richiesta di ricezione (get)
oppure di invio (put) del file in questione. Una volta ricevuta questa
richiesta, il servizio di File Sharing attivo sul nodo remoto la
analizzerà, decidendo il da farsi sulla base di tre possibili scenari.
Nel primo scenario, il servizio ha ricevuto una richiesta di get e il
nome del file è vuoto. In questo caso, il nodo remoto invia al client
l’intera lista dei file accessibili. Nel secondo scenario, si è in
presenza di una richiesta di get di un file specifico. In questo caso, il
server invia al client uno stream di byte alla porta del client presente
nella richiesta, utilizzando le API del middleware RAMP. In

42
particolare, viene utilizzato sendUnicast offerto dalla classe
E2EComm per l’invio del file serializato, mentre per la ricezione si
utilizza receive, sempre offerto da E2EComm. In questo modo si
sfruttano tutte le potenzialità di RAMP ampiamente descritte nel
Capitolo 2. Infine, l’ultimo scenario è la ricezione di una richiesta di
put. In questo caso, il server invia al client la porta su cui è pronto a
ricevere il suddetto file, mentre il client, dopo aver ricevuto la porta
del server, provvede all’invio dello stream utilizzando le API di
RAMP.
Inoltre, è disponibile una applicazione Android che permette la
portabilità di RAMP su tutti i dispositivi dotati di questo sistema
operativo. In particolare, è presente un progetto Android denominato
RampAndroid. Esso utilizza come libreria il progetto RAMP,
definendo nuove interfacce grafiche specifiche per Android ed
implementando servizi specifici al mondo mobile. In questo modo, si
è resa possibile la portabilità del middleware RAMP nel mondo
Android con costi implementativi ridotti. Infatti, è stato possibile
importare il progetto originario scritto in linguaggio Java ed utilizzarlo
direttamente come libreria del nuovo progetto Android, anch’esso
scritto in linguaggio Java. Ciò apre nuovi scenari, in cui è possibile
sia creare nuove applicazione utilizzanti nativamente il middleware
RAMP come libreria, sia utilizzare il middleware RAMP come proxy
accanto ad applicazioni preesistenti, analogamente a quanto già
descritto nel Capitolo 2 analizzando il progetto base di RAMP.
Inoltre, in questa applicazione, di cui sono rappresentati alcuni
screenshot dell’interfaccia grafica principale nella Figura 22, è
comunque disponibile il client ed il servizio di File Sharing
precedentemente descritti. Infatti, l’interfaccia grafica (Figura 23) è
stata ridisegnata appositamente per il mondo Android, ma si
utilizzano sempre le funzionalità offerte dalle classi
FileSharingClient e FileSharingService del progetto
RAMP, analizzate precedentemente. Dunque, il protocollo di invio e
ricezione dei file risulta essere invariato sia per dispositivi fissi sia
per dispositivi mobili Android, rendendo possibile la creazione di reti
ibride fisse e mobili, in cui sono attivi servizi di condivisione di file e
contenuti creati dall’utente.

43
Figura 22. Interfaccia grafica principale dell’applicazione Android RAMP: a sinistra è
raffigurata la schermata principale; a destra è riportato il menu
dell’applicazione, in cui è possibile accedere ai servizi e ai client disponibili.
Figura 23. Interfaccia grafica del client (a sinistra) e del servizio (a destra) di File
Sharing nell’applicazione Android RAMP.

44
3.2 ANALISI DEL PROBLEMA
In questo contesto sorgono diversi problemi che il progetto di tesi si
pone di risolvere, come ad esempio la possibile introduzione di una
cache passiva in reti in cui il traffico è passante per un nodo
specifico oppure la possibilità di introdurre una cache proattiva che
possa far ridurre il tempo di latenza di una richiesta attraverso reti
UMTS, spostando i contenuti sulla rete locale. In particolare, nel
Paragrafo 3.2.1 saranno analizzati due diversi possibili casi d’uso,
esemplificativi dei problemi che potrebbero emergere.
3.2.1 POSSIBILI CASI D’USO
Per spiegare nel modo migliore e più chiaro possibile i possibili
scenari critici del sistema preesistente di File Sharing di RAMP,
verranno di seguito introdotti due casi limite, volutamente
semplificati per chiarezza espositiva. In particolare, nel Paragrafo
3.2.1.1 sarà analizzata una rete locale in cui sono presenti
solamente tre nodi, mentre nel Paragrafo 3.2.1.2 sarà esaminata
una rete con tre nodi, di cui uno mobile, ad esempio uno
smartphone Android. In entrambi gli scenari sono attivi un servizio e
un client di File Sharing, tipicamente su nodi differenti.
3.2.1.1 File Sharing Service in una rete ad-hoc
Nel primo caso d’uso presentato, sono presenti tre nodi distinti su
cui è attivo il middleware RAMP connessi come in Figura 24
attraverso collegamenti ad-hoc (istaurati ad esempio tramite
protocollo IEEE 802.11 o Bluetooth). Nel nodo C è attivo un servizio
di File Sharing. L’utente vuole accedere ai contenuti condivisi dal
nodo C attraverso un il client di File Sharing di RAMP attivo sul nodo
A.
Figura 24. Possibile rete formata da tre nodi distinti in cui è attivo RAMP.

45
In questo scenario, a causa della topologia della rete, tutte le
richieste get o put di file dovranno necessariamente transitare
attraverso il nodo B. Inoltre, anche lo stream di byte rappresentante
il file in download dovrà passare inevitabilmente attraverso B. Ciò
rende il nodo B un ottimo candidato per ospitare un servizio di
monitoraggio del traffico di File Sharing sulla rete locale. Inoltre, il
nodo B potrebbe essere in grado di fare caching passiva dei file in
transito attraverso di lui e, successivamente, al ripresentarsi di una
richiesta per lo stesso file, potrebbe inviare il proprio file in cache al
nodo A in modo trasparente al nodo A e C. In questo modo, si
potrebbe risparmiare una hop nel caso in esame, con conseguente
diminuzione della latenza per l’utente finale. È inoltre evidente che,
in scenari in cui sono presenti molti più nodi e/o reti spontanee,
questo risparmio potrebbe non limitarsi ad un singolo hop e quindi
potrebbe essere molto utile e consistente.
3.2.1.2 File Sharing Service attivo su device Android
Nel secondo caso d’uso, sono presenti quattro nodi connessi come
in Figura 25a. In particolare, il nodo D è costituito da un dispositivo
mobile con sistema operativo Android su cui è attivo un servizio di
File Sharing, inizialmente connesso al nodo B attraverso una
connessione ad-hoc (ad esempio IEEE 802.11 o Bluetooth).
Figura 25. Possibile scenario d’uso. Un dispositivo Android (nodo D)

46
Il client, attivo sul nodo A, richiede il download di diversi contenuti
disponibili sul dispositivo mobile. Finché la connessione ad-hoc fra il
nodo B e D rimane attiva, i file fluiscono attraverso la rete locale e,
in particolare, attraversano il nodo B. Come appena descritto nel
Paragrafo 3.2.1.1, il nodo B potrebbe fungere da cache passiva dei
file maggiormente richiesti. Tuttavia, nel caso in cui la connessione
tra il nodo B e il nodo D cadesse, questa cache risulterebbe
inefficace e inutilmente onerosa per B dal punto di vista delle risorse
occupate. Infatti, il nodo D si connetterebbe al nodo C attraverso la
rete UMTS e nuove richieste di file da parte del client non sarebbero
più intercettate da B. Questo scenario pone una nuova sfida: creare
una cache che possa fornire i dati proattivamente, senza dover per
forza intercettare le richieste di get, ma rispondendo alle richieste di
un servizio di File Sharing remoto. Se, a questo punto, il nodo B
fosse in grado di fornire al client A la propria copia cache richiesta
attivamente dal nodo D, il file fluirebbe direttamente dal nodo B al
nodo A, evitando al nodo D di inviare il file attraverso la rete UMTS
(tipicamente onerosa per quanto riguarda costi energetici e dotata di
banda limitata).
3.3 POLITICHE DI MONITORAGGIO E DI RE/PLACEMENT
Per risolvere i problemi emersi dall’analisi del Paragrafo 3.2, si è
deciso di adottare le seguenti politiche di alto livello di gestione del
monitoraggio del traffico di File Sharing e di gestione del
piazzamento e del rimpiazzamento dei contenuti generati
dall’utente.
In particolare, per quanto riguarda la gestione del monitoraggio del
traffico di File Sharing, si è deciso di inserire al termine del
passaggio di un file un nuovo record alla raccolta dei trasferimenti
passati attraverso il nodo. Successivamente, chiunque voglia
analizzare i dati del traffico, potrà ottenere le informazione relative ai
file transitati, alle loro dimensione, agli istanti di tempo relativi alla
loro richiesta e alle occorrenze di tali file, semplicemente
richiedendoli alla classe gestore del traffico.
Per quanto riguarda le politiche di placement e replacement della
cache, si è deciso di utilizzare due pattern strategy, in modo da

47
consentire futuri inserimenti di nuove politiche in maniera semplice e
veloce. Analogamente alle politiche appena citate, si utilizza un
modulo generico anche per la cache vera e propria, permettendo,
ad esempio, che i file possano essere memorizzati in una mappa di
stream di byte risiedenti nell’heap oppure direttamente sul file
system locale. In particolare, per quanto riguarda la politica di
placement, si è deciso di adottare una strategia di default, il cui
pseudocodice è presentato nel Listato 1 e i cui punti salienti sono
descritti nell’elenco seguente.
 Per prima cosa, non si mantiene copia cache nei casi banali in
cui il file sia inviato dal nodo corrente oppure in cui la
grandezza del file sia superiore a quella massima consentita
alla cache.
 Successivamente, la strategia di default prende in esame il caso
di burst di richieste. Infatti, se nell’ultimo lasso di tempo
specificato dalla proprietà burstTimeThreshold, inserita nel file di
configurazione di RAMP e caricata a runtime, si sono registrati
più di burstOccurrencesThreshold trasferimenti (altra proprietà),
si mantiene copia in cache. In particolare, per le due proprietà
appena citate e per le successive, si è deciso di utilizzare il
sistema di caricamento delle proprietà fornito da RAMP e di non
cablarle hardcoded nel sorgente in quanto si è voluto lasciare un
ulteriore grado di personalizzazione all’utente, senza che sia
necessario ricompilare l’intero sistema.
 Proseguendo, non si effettua caching passivo nei primi
firstTimesNotToCache passaggi del file, per evitare di occupare
inutilmente risorse per file richiesti raramente.
 Successivamente, con l’aiuto di un array, si costruisce un
istogramma in cui si suddividono le occorrenze dei trasferimenti
dello stesso file nel tempo, raggruppandoli con granularità
sliceGranularity.
 A questo punto, si analizza l’istogramma ottenuto: se è presente
un solo slice temporale, si effettua caching. Infatti, si presume
che la popolarità di un file nel tempo si comporti come una curva
inizialmente crescente, successivamente stabile e infine
decrescente. Un esempio della curva di popolarità è illustrato in

48
Figura 26. Quindi, se è presente un solo slice temporale e si è
rispettato il vincolo di firstTimesNotToCache, siamo nella fase
iniziale della curva di popolarità, perciò conviene mantenere una
copia nella cache locale.
 In seguito, sono calcolati il numero di ultimi slice in cui le
occorrenze sono cresciute o al più rimaste invariate, sempre
al fine di capire se ci si trova nella parte iniziale della curva di
popolarità. Nel caso in cui il numero appena ricavato sia
maggiore o uguale alla proprietà lastIncInARowThreshold, si
conserva copia cache.
 Infine, si vuole evitare di non mantenere copia cache nel caso ci
sia una momentanea diminuzione delle occorrenze, ma si
rimanga comunque nella parte crescente o nel plateau della
curva di popolarità. Per questo motivo, se il valore dell’ultimo
slice dell’istogramma è maggiore del valore più alto di tutti gli
slice (considerando un margine percentuale di tolleranza del
tolerancePercentageThreshold percento), si mantiene copia
cache.
 In tutti gli altri casi, non si effettua caching passivo del file.
Figura 26. Istogramma di popolarità di un file e sua approssimazione polinomiale.
0
2
4
6
8
10
12
14
Occorrenze(#)
Tempo
Popolarità
Polinomiale

49
INITIALIZE properties from “ramp.props”
IF this node sent the file
no cache
IF the file is bigger than the cache size
no cache
IF the file’s occurrences in the last burstTimeThreshold are
more than burstOccurrences
cache
IF the total occurrences are less than fistTimesNotToCache
no cache
INITIALIZE an histogram built from file’s occurrences
IF the size of the histogram is 1
cache
IF the last increasing slices of the histogram are more than or
equal to lastIncInARowThreshold
cache
IF the value of the last slice is bigger than the biggest slice
minus tolarancePercentageThreshold %
cache
no cache
Listato 1. Pseudocodice della strategia di placement di default.
Mentre, per quanto riguarda la decisione sulla necessità di
effettuare il replacement, si è deciso di adottare una strategia di
replacement di default in cui si controlla che vi sia sufficiente spazio
nella cache per ospitare il nuovo file. In caso non ve ne sia, sarà
necessario eseguire un rimpiazzamento dei file nella cache, mentre
non è necessario nel caso un cui vi sia sufficiente spazio libero. Nel
caso in cui è necessario liberare spazio prima di un nuovo
piazzamento, la strategia di default consiste in una politica di
replacement ibrida. Infatti, la strategia che si è deciso di adottare
presenta le seguenti caratteristiche:

50
 inizialmente sfrutta un algoritmo LFU (Least Frequently Used,
descritto nel Paragrafo 1.2.2) su di un periodo ti tempo limitato
rappresentato dai secondi descritti dalla proprietà
moreFrequentTimeThreshold, privilegiando quindi i file richiesti
più frequentemente e tentando di lasciarli nella cache per
successive probabili richieste;
 in seguito, nel caso in cui esistano file con la stessa frequenza,
viene utilizzato un algoritmo LRU (Least Recently Used, sempre
descritto nel Paragrafo 1.2.2), in cui vengono privilegiati i file
richiesti più recentemente.
In altre parole, si decide di rimuovere dalla cache il file meno
frequente negli ultimi moreFrequentTimeThreshold secondi e, in
caso di parità di frequenza, si elimina il file che non è stato richiesto
da più tempo.
3.4 ARCHITETTURA DELLA SOLUZIONE
Per chiarezza espositiva, l’architettura della soluzione proposta in
questo progetto di tesi è stata suddivisa in tre sottosoluzioni relative
a tre differenti problemi emersi nel Paragrafo 3.2. Come sarà chiaro
proseguendo con la lettura, i tre casi potranno poi essere racchiusi
in un unico nuovo servizio software che si occuperà sia di
monitorare il traffico passante, sia di effettuare cache passiva e di
rispondere attivamente alle richieste di invio di file risiedenti nella
propria cache. In particolare, nel Paragrafo 3.4.1 sarà analizzata la
soluzione proposta per il monitoraggio del traffico, mentre nel
Paragrafo 3.4.2 e nel Paragrafo 3.4.3 saranno analizzate le
soluzioni di cache passiva e proattiva. Infine, nel Paragrafo 3.4.4
sarà esposta l’architettura complessiva del sistema.
3.4.1 MONITORAGGIO DEL TRAFFICO DI FILE SHARING
Per quanto riguarda il monitoraggio del traffico di File Sharing
passante per un nodo, si è deciso di realizzare un componente
chiamato FileSharingPacketListener (FSPL). Questo nuovo
componente implementa l’interfaccia del core di RAMP chiamata
PacketForwardingListener (PFL). In questo modo,
registrandosi al Dispatcher, FSPL potrà analizzare tutti i pacchetti

51
passanti per il nodo. In particolare, saranno invocati i metodi relativi
al pacchetto o all’header specifico passante in quel momento per il
nodo corrente. Inoltre, FSPL si appoggia alle API fornite da un altro
nuovo modulo chiamato FileSharingTrafficObserver
(FSTO), il cui scopo è quello di raccogliere e presentare le
informazioni derivanti dall’osservazione del traffico di File Sharing.
3.4.2 CACHE PASSIVA
Per quanto riguarda la realizzazione di una cache passiva, si è
deciso di aggiungere un nuovo componente denominato
FileSharingCacheManager (FSCM). FSPL, al momento di una
nuova richiesta, invocherà le API di FSCM per sapere se la cache
locale è in possesso di una copia del file. In caso di risposta
affermativa, FSPL provvederà ad inviare il file direttamente al client,
non inoltrando al server la richiesta originaria. Inoltre, nel caso del
passaggio di un nuovo file, FSPL interrogherà FSCM sulla necessità
di mantenerne una copia nella cache passiva. In caso si intenda
mantenerne una copia, FSPL avrà il compito di intercettare i payload
parziali costituenti il file, ricomporli e memorizzare il file risultante in
cache, pronto per l’invio a seguito di successive richieste. Nel caso
di spazio insufficiente nella cache, FSPL dovrà anche provvedere a
effettuare un replacement della cache.
3.4.3 CACHE PROATTIVA
Per quanto riguarda la cache proattiva, si è deciso di realizzare un
nuovo servizio chiamato FileSharingCacheService (FSCS). Si
è inoltre modificato il vecchio servizio di File Sharing in modo che,
se specificato dall’utente, si contatti un servizio FSCS
preselezionato e si possa richiedere l’invio di un file da parte dello
stesso FSCS nel caso in cui esso disponga di una copia in cache.
Questo nuovo servizio utilizzerà le API fornite da FSCM per la
gestione e l’accesso alla cache, controllando la presenza o meno
del file richiesto proattivamente e, se presente, inviandolo al client
specificato nella richiesta.

52
3.4.4 SOLUZIONE COMPLESSIVA
Cercando di rendere disponibili tutti e tre le soluzioni analizzate nei
paragrafi precedenti, si è deciso di includere FSPL all’interno del
servizio FSCS, creando così un componente di alto livello chiamato
FileSharingContentReplacer in grado sia di effettuare cache
passiva, sia di rispondere proattivamente alle richieste di server di
File Sharing esterni. In Figura 27 è riportato lo schema architetturale
complessivo della soluzione proposta.
3.5 REALIZZAZIONE IMPLEMENTATIVA
Nei paragrafi seguenti saranno analizzate nel dettaglio le classi
sviluppate, giustificando di volta in volta le scelte implementative
adottate. Analogamente al Paragrafo 3.4, l’analisi della realizzazione
implementativa è stata suddivisa in tre Paragrafi, riguardanti
sottoproblemi del sistema software complessivo: nel Paragrafo 3.5.1
saranno esaminate le scelte implementative riguardanti il
monitoraggio del traffico di File Sharing, nel Paragrafo 3.5.2 saranno
presentate quelle riguardanti la realizzazione di una cache passiva
e, infine, nel Paragrafo 3.5.3 saranno analizzate quelle relative alla
realizzazione di un servizio di cache proattiva alle richieste remote.

53
Figura 27. Architettura di FileSharingContentReplacer e relazioni fra i nuovi
moduli.
3.5.1 IMPLEMENTAZIONE DEL MONITORAGGIO DEL TRAFFICO DI FILE
SHARING
Come descritto nel Paragrafo 3.4.1, si intende realizzare un
sottosistema software in grado di monitorare il traffico di filesharing
passante per il nodo RAMP locale. Si dispone di un’interfaccia del
core RAMP chiamata PacketForwardingListener (PFL), la cui
implementazione e la successiva registrazione al Dispatcher RAMP
permette l’osservazione dei pacchetti e degli header in transito
attraverso il nodo. In particolare, il PFL espone metodi che saranno
chiamati dal Dispatcher al passaggio di un header
(receivedTcpUnicastHeader), di un pacchetto unicast
(receivedTcpUnicastPacket) o di un payload parziale
(receivedTcpPartialPayload). Nello snippet di Listato 2 è
riportata l’implementazione dell’interfaccia PFL e dei relativi metodi.

54
public interface PacketForwardingListener {

void receivedUdpUnicastPacket(UnicastPacket up);
void receivedUdpBroadcastPacket(BroadcastPacket bp);

void receivedTcpUnicastPacket(UnicastPacket up);
void receivedTcpUnicastHeader(UnicastHeader uh);
void receivedTcpPartialPayload(UnicastHeader uh, byte[] payload,
int off, int len, boolean lastChunk);
void receivedTcpBroadcastPacket(BroadcastPacket bp);

void sendingTcpUnicastPacketException(UnicastPacket up, Exception e);
void sendingTcpUnicastHeaderException(UnicastHeader uh, Exception e);

}
Listato 2. Implementazione dell’interfaccia PacketForwardingListener del core
RAMP.
Figura 28. Scambio di pacchetti e payload parziali tra client e servizio di File Sharing
in RAMP prima del progetto di tesi.
Inoltre, analizzando il protocollo di File Sharing tra il client e il
servizio (Figura 28) nell’ottica degli oggetti che attraversano il FSPL
nei diversi istanti di tempo, è emerso un nuovo problema
implementativo. In particolare, nella Figura 28 è rappresentata la
richiesta di get di un file, la quale è articolata nei seguenti passaggi
salienti:
1) la richiesta di get di un file viene inviata dal client sul nodo A
verso il nodo C e raggiunge per primo il nodo B;
2) La richiesta viene inviata dal nodo B al nodo C;
3) il nodo C risponde inviando uno stream di byte corrispondente al
file serializzato verso il nodo A, raggiungendo per primo il nodo
B;
4) il nodo B inoltra lo stream di byte al nodo client A.

55
In questo modo, il nodo in cui è registrato il FSPL (nodo B) vedrà
passare la richiesta del file e i payload parziali corrispondenti in due
istanti di tempo diversi, senza nessuna possibilità di collegare la
richiesta al file. Ciò costituisce un grosso problema per l’analisi del
traffico e per la futura implementazione della cache passiva, in
quanto potrebbero passare diversi file attraverso il nodo B e non è
detto che l’ordine delle richieste sia lo stesso dell’ordine di
passaggio dei file (tipicamente i payload parziali di più file
provenienti da server remoti differenti saranno visti sovrapposti nel
tempo dal nodo B). Per risolvere questo problema, si è deciso di
modificare il protocollo di comunicazione fra client e server di File
Sharing, anteponendo all’invio del file da parte del server un nuovo
oggetto chiamato FileSharingTransferHeader (FSTH), il cui
diagramma UML è rappresentato in Appendice A1. In particolare,
FSTH ha il compito di raccogliere le informazioni che legano la
richiesta di un file allo stream di byte (payload parziali)
corrispondente. Per questo motivo, il server, una volta ricevuta una
richiesta per un file, crea una nuova istanza di FSTH,
inizializzandola con le informazioni contenute nella richiesta ricevuta
(come ad esempio nome del file, la sua grandezza e l’ID del nodo
richiedente e del nodo che possiede la risorsa). A questo punto,
serializza la nuova istanza di FSTH e la inserisce in testa allo
stream di byte diretto al client. In questo modo, FSPL è in grado di
conoscere tutte le informazione relative al file che lo attraversa
prima che lo abbia effettivamente attraversato. Ad esempio è in
grado di conoscere la grandezza dello stream di byte corrispondente
al file serializzato prima di vederlo passare completamente. Infatti,
non appena ha ricevuto il FSTH in testa allo stream conosce già la
grandezza in byte del file corrispondente. In Figura 29 è raffigurato il
nuovo protocollo di comunicazione dopo l’inserimento del FSTH
(colorato in scuro). In questo modo, il FSPL è in grado di notificare
alla propria istanza della classe FileSharingTrafficObserver
(FSTO) il passaggio di un file. In particolare, attraverso la classe di
appoggio FileSharingTransferInfo (FSTI), si memorizzano in
una HashMap i dati relativi all’istante di tempo di creazione della
richiesta (campo aggiunto alla richiesta preesistente per avere una

56
collocazione temporale utile nell’analisi del traffico), al nome del file,
alla sua grandezza, all’ID del nodo richiedente e all’ID del nodo
possessore del file. Viene così creato un archivio dei precedenti
passaggi di file, il quale rende possibile ricreare la storia del traffico
di File Sharing passante per il nodo in cui è attivo il FSPL. Per
quanto riguarda il diagramma UML delle classi FSTO e FSTI si
faccia riferimento all’Appendice A2.
Figura 29. Scambio di pacchetti e payload parziali tra client e servizio di File Sharing
dopo l’introduzione del FSHT in testa allo stream di byte (in scuro).
3.5.2 IMPLEMENTAZIONE DELLA CACHE PASSIVA
Come descritto nel Paragrafo 3.4.2, si intende realizzare un
sottosistema software in grado di effettuare caching passiva dei file
che attraversano il nodo solo nel caso in cui, a seguito di opportune
valutazioni, sia ritenuto necessario. Inoltre, il sottosistema deve
essere in grado di inviare la copia cache locale al client in seguito
della ricezione di una nuova richiesta per lo stesso file. Dal punto di
vista implementativo, è stata ampliata la classe FSPL già introdotta
precedentemente e i cui dettagli sono analizzati nel Paragrafo
3.5.2.1. Successivamente, saranno analizzate la classe
FileSharingCacheManager (FSCM) nel Paragrafo 3.5.2.2,
l’interfaccia PlacementStrategy (PS) e sue relative
implementazioni nel Paragrafo 3.5.2.3, l’interfaccia
RelacementStrategy (RS) e sua implementazione di default nel
Paragrafo 3.5.2.4 e, infine, la classe astratta CachedFiles (CF) e
relative sottoclassi nel Paragrafo 3.5.2.5.

tesi_Lelli_Matteo_finale

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (8)

Similar to tesi_Lelli_Matteo_finale

Similar to tesi_Lelli_Matteo_finale (20)

tesi_Lelli_Matteo_finale