relazione

Delay Tolerant Networking Service per SAMOA
Nicola Azzini – [email protected]
sfruttando informazioni relative all'ambiente
in cui si opera. Per contesto si intendono le
persone, i luoghi e le cose presenti
nell'ambiente fisico circostante. In questo
nuovo scenario la rete sociale deve essere
estratta utilizzando, oltre alle informazioni
personali sugli interessi degli utenti, anche
quelle relative al contesto, come la prossimità
fisica tra gli utenti ed il luogo in cui avviene
la collaborazione. Per fornire servizi di social
computing context-aware bisogna risolvere
alcune sfide tecniche. Innanzitutto, sono
necessari meccanismi e strumenti per rilevare
la prossimità fisica tra gli utenti ed indicare il
luogo in cui si opera. Inoltre, occorre un
linguaggio comune per definire interessi e
caratteristiche degli utenti interessati alla
collaborazione.
A differenza dei servizi di social networking
basati sul web, gli ambienti mobili di
ubiquitous-computing sono molto più
dinamici. E’ quindi necessario un differente
approccio alla progettazione. In questi
ambienti la topologia della rete non è
determinabile a priori: è perciò impossibile
fare assunzioni sulle identità e sulle
caratteristiche dei membri che ne faranno
parte. A causa dell'elevata mobilità,
disconnessioni, partizioni e merge della rete
sono eventi frequenti che causano transitori
nella collaborazione e che rendono difficile la
gestione della rete sociale.
Socially Aware and MObile Architecture
(SAMOA)[1] è un middleware che integra un
insieme di facilities per la gestione, la
personalizzazione e la propagazione della rete
sociale a livello applicativo.
Allo stato dell’arte SAMOA consente la
comunicazione solamente agli utenti che sono
in prossimità fisica.
In scenari di emergenza (Emergency Rescue),
in cui è possibile che nodi della rete sociale
rimangano isolati per un tempo prolungato, è
necessario sviluppare un servizio che
permetta ad ogni utente di inoltrare messaggi
Sommario –Il middleware SAMOA consente
di gestire e popolare la rete sociale e
propagare a livello applicativo la visibilità
dei membri al fine di promuovere e
supportare
applicazioni
collaborative
avanzate, ma limita la comunicazione tra le
entità direttamente connesse. Nel nostro
progetto
abbiamo
esteso
SAMOA,
sviluppando un servizio per favorire la
comunicazione e lo scambio di file tra entità
appartenenti a reti sociali differenti oppure
appartenenti alla medesima rete sociale ma
non direttamente connesse. Abbiamo tenuto
conto di uno scenario in cui possono essere
presenti nodi dotati di risorse computazionali
e di memoria limitate e in cui possano
verificarsi situazioni di emergenza, cioè dove
uno o più nodi della rete sociale globale
rimangono isolati per un tempo prolungato.
Deve pertanto essere possibile per questi nodi
poter inoltrare messaggi alla prima entità,
dotata di sufficienti risorse, con cui entrano
in prossimità fisica.
Il servizio sviluppato opera tra SAMOA[1] e
il livello applicativo, e fornisce funzionalità
per l’invio, il forwarding, la memorizzazione
e la ritrasmissione di messaggi Delay
Tolerant.
Keywords: Social Computing, Emergency
Rescue, Delay Tolerant Network
I – Introduzione
Si definisce rete sociale l'insieme dei legami
che uniscono gli individui che condividono
gli stessi interessi e le stesse attività.
Il continuo miglioramento delle tecnologie
wireless e l'enorme disponibilità di dispositivi
portabili che le supportano, hanno condotto
allo studio di nuovi modelli di comunicazione
che tengono conto del contesto in cui si opera.
Il context-aware computing adatta il
funzionamento del sistema di comunicazione
-1-
alla prima entità, con sufficienti risorse
computazionali e di memoria, con cui entra in
prossimità fisica.
Al fine di permettere l’utilizzo di SAMOA in
scenari di Emergency Rescue, è pertanto
necessario sviluppare un servizio che renda
possibile la comunicazione a entità non
direttamente connesse, prevedendo strutture
dati per la memorizzazione locale di
messaggi, meccanismi di forwarding tra entità
che entrano in prossimità fisica e meccanismi
di ritrasmissione per i messaggi che vengono
persi a causa di disconnessioni temporanee.
Per realizzare questo servizio abbiamo preso
spunto dalla Delay Tolerant Network
Architecture [2] . Questa architettura è stata
sviluppata per operare in reti di
interconnessione caratterizzate da frequenti
partizioni e disconnessioni, dove è possibile la
presenza di nodi con risorse computazionali e
di memoria limitate.
La DTN Architecture opera sopra i livelli di
rete e trasporto delle reti che interconnette e
fornisce
servizi
chiave
come
la
memorizzazione, la ritrasmissione e il
forwarding di messaggi asincroni al fine di
fornire affidabilità alla comunicazione del
sistema distribuito in cui viene integrata.
Per comprendere il funzionamento della DTN
Architecture bisogna considerare i concetti di
regione e di DTN gateway. Una regione è una
parte della rete globale che comprende uno o
più nodi. Un DTN gateway è un nodo della
rete, con consistenti risorse computazionali e
di memoria, che è responsabile della
memorizzazione
dei
messaggi
Delay
Tolerant, che riceve dagli altri nodi della rete,
e del forwarding dei messaggi memorizzati ai
nodi con cui entra in prossimità fisica.
I DTN gateway, pertanto, ricoprono il ruolo
fondamentale per il funzionamento della DTN
Architecture.
La rete sociale è centrata sull'utente e utilizza
due tipologie di visibilità di contesto:
 la visibilità del luogo in cui l’utente si
trova, chiamata place visibility;
 la visibilità delle richieste e delle
caratteristiche del luogo e dell’utente,
detta profile visibility.
Utilizzando la prima informazione di contesto
si restringe lo spazio per l'estrazione della rete
sociale alle sole entità presenti nello stesso
luogo fisico; mentre, le informazioni
contenute nel profilo permettono di raffinare
ulteriormente la rete sociale includendo in
essa solo i luoghi e gli utenti che
corrispondono realmente alle necessità e alle
richieste dell'utente.
SAMOA modella e rappresenta queste
informazioni di contesto attraverso metadati e
utilizza algoritmi di matching semantico per
analizzare i profili e inferire eventuali
compatibilità semantiche.
Figura 1. Un esempio di rete sociale estratta da
SAMOA da una mobile ad-hoc network
La rete sociale di SAMOA viene modellata
tenendo conto di tre possibili ruoli assegnabili
ad un' entità. Il ruolo di Manager viene
assunto dagli utenti che sono interessati a
creare una propria rete sociale. Essi hanno la
responsabilità di definire i confini della
località e i criteri che guideranno l'estrazione
dei collaboratori. Tutti gli utenti che sono
presenti all'interno dei confini stabiliti dal
Manager sono detti Client sono i candidati a
diventare i membri della rete sociale. Quando
II – Stato dell’arte: il framework SAMOA
SAMOA supporta la creazione di reti sociali
semantiche
context-aware
tra
utenti
fisicamente vicini, con stesse attitudini e
interessi.
2
essi entrano a far parte di una rete sociale
assumono il ruolo di Member.
Ogni entità può assumere tutti i ruoli anche
contemporaneamente.
In SAMOA, la gestione della rete sociale è
basata sul concetto di Place. Ogni Manager
ne definisce uno e ne rappresenta il centro. Il
Place è l'insieme dei Client che sono
fisicamente vicini al Manager.
Il concetto di vicinanza varia in base
all'ambiente di lavoro. In una rete
infrastrutturata si definiscono vicini tutti i
dispositivi collegati alla stessa cella.
Mentre, in una MANET sono definiti vicini
tutti i dispositivi connessi al Manager da un
percorso di routing di lunghezza massima di h
network hop.
Il numero h di hop è detto place radius.
Utilizzando questa definizione di vicinanza, il
numero di partecipanti alla rete sociale non
può essere determinato a priori: esso varia
dinamicamente con il movimento degli utenti.
I Place si possono sovrapporre e, quindi, gli
utenti possono partecipare a più reti sociali
contemporaneamente.
Ogni entità SAMOA ha un identificativo
univoco (UUID) associato ad un profilo che
descrive le sue caratteristiche. Il Manager ha
un Place Profile che lo identifica, lo descrive
ed elenca le attività di suo interesse. Ad
esempio, una biblioteca potrebbe avere come
attività lo studio, la lettura, la consultazione di
cataloghi e il prestito. Ogni utente SAMOA,
sia esso Manager, Client o Member, ha un
User Profile che lo descrive e ne definisce le
attività e le preferenze. Ad esempio, uno
studente potrebbe essere interessato all'attività
di prestito di libri esprimendo la preferenza
sull'argomento.
Ogni Manager è provvisto anche di un
Discovery Profile che impone dei vincoli
sulle preferenze che i Client devono avere per
essere accettati nella sua rete sociale.
Nel seguito verranno descritti i servizi chiave
necessari alla comunicazione context-aware e
alla realizzazione di reti sociali.
Figura 2. L’architettura di SAMOA
Il Basic Services Layer fornisce un servizio di
nomi, un meccanismo per la rilevazione di
entità presenti nella medesima località e dei
metodi per supportare la comunicazione sia
essa di tipo uno a molti o uno a uno.
Il Message Transport Manager (MTM)
realizza e mette a disposizione dei metodi per
la comunicazione punto-punto e puntomultipunto. Attualmente la comunicazione è
realizzata attraverso un modulo basato sul
protocollo UDP ma esso può essere sostituito
a boot time con un modulo che realizzi, ad
esempio, una comunicazione basata su
bluetooth
(che
è
stato
sviluppato
ultimamente). La comunicazione punto-punto
permette di inviare messaggi ad un'altra entità
SAMOA identificata da un indirizzo (IP nel
caso
si
utilizzi
UDP)
mentre
la
comunicazione punto-multipunto permette di
inviare messaggi in broadcast a tutte le entità
che si trovano nella medesima località.
Il Location/Proximity Manager (L/PM) ha il
compito di generare nomi unici. Tali nomi
sono statisticamente univoci e sono conformi
allo standard UUID. Questo servizio permette
ad un'entità di segnalare la propria presenza
on-line attraverso l'invio, ad intervalli
regolari, di un messaggio broadcast di
presenza contenete il proprio UUID.
Esso, inoltre, riceve tutti i messaggi di
presenza inviati. Ogni messaggio ricevuto
viene inserito in una tabella ed etichettato con
un time-stamp: se non viene ricevuto un
nuovo messaggio di presenza entro una certa
soglia, si considera quell'utente disconnesso.
III – L’architettura
I servizi che compongono SAMOA sono
organizzati in tre layer logici, realizzati al di
sopra della Java Virtual Machine (Fig. 2).
3
Il Social Network Management Layer fornisce
meccanismi per l'estrazione della rete sociale
e per la sua gestione.
Il Profile Manager (PM) permette di gestire i
profili e la loro distribuzione. Un'entità
SAMOA che funge da Manager distribuisce
attraverso il PM il Place Profile (PP) a tutte le
entità presenti nella località (individuate
grazie all' L/PM).
Quando il PM di un'entità riceve un PP si
coordina con il Semantic Match Engine
(SME) per controllare se e quale attributo
contenuto nel suo profilo utente (UP) è
compatibile con le attività dichiarate dal PP.
A questo punto l'utente invia solo le attività
compatibili al Manager il quale, sempre
attraverso l'ausilio del SME, deciderà se
inserire o meno l'utente nella sua rete sociale.
Per fare ciò utilizza un Discovery Profile (DP)
in cui sono contenuti i vincoli a cui un UP
deve sottostare per essere accettato nella sua
rete sociale.
L’SME supporta il PM nello screening dei
profili e prevede due algoritmi semantici
differenti. Il primo, eseguito sul client, prende
in input il PP del Manager e l'UP del Client
restituendo le sole attività compatibili fra i
due. Il secondo algoritmo, eseguito sul
Manager, prende in input il risultato del primo
e il DP: se i vincoli sono soddisfatti il Client
diventa Member della rete sociale.
Il Place-dependent Social Network Manager
(PSNM) si occupa di gestire una vista
aggiornata dei membri della rete sociale
connessi. Questo servizio si coordina con il
L/PM per sapere quando un utente si connette
o si disconnette ed ottiene dal PM gli UP e gli
UUID delle entità compatibili. Memorizza
questi dati in una tabella rendendoli
disponibili alle applicazioni e notificando ad
esse quando un'entità cambia di stato (si
connette o si disconnette).
Il Global Social Network Manager (GSNM)
mantiene in memoria permanente tutte le reti
sociali place-dependent, memorizzando gli
UUID delle entità e i loro profili. Per ogni
Member viene inoltre memorizzato il PP e il
DP che hanno guidato la sua selezione.
Il Delay Tolerant Network Manager (DTNM)
fornisce il servizio per la gestione di messaggi
Delay Tolerant, inviati a entità SAMOA non
necessariamente connesse in modo diretto. Il
DTNM si interfaccia con tutti i moduli
sottostanti. Ogni entità è dotata di una cache,
con gestore della persistenza, per la
memorizzazione di messaggi Delay Tolerant
e di un gestore dello stato.
IV – Lavoro svolto
Il servizio di Delay Tolerant Networking per
SAMOA si occupa dell’invio/ricezione di
messaggi DT, della loro memorizzazione, del
forwarding e inoltre della ritrasmissione di
messaggi che vengono persi a causa di
disconnessioni temporanee.
Il modello del servizio integra il modello di
SAMOA con il modello della DTN
Architecture. Difatti abbiamo comparato il
concetto di regione della DTN Architecture
con il concetto di Place-dependent Social
Network di SAMOA. Inoltre, al fine di
bilanciare
in
modo
opportuno
le
responsabilità tra le entità della rete globale, il
gateway della DTN Architecture è stato
assimilato dal manager di SAMOA.
Siccome il Delay Tolerant Networking
Service estende SAMOA, le entità possono
assumere i ruoli di manager oppure di client.
Sia i client che i manager possono essere
sender e/o receiver di messaggi DT. I
manager sono entità dotate di buone risorse,
sia computazionali che di memoria, e
svolgono anche la funzione di forwarder. I
client, invece, sono entità con scarse risorse
computazionali e/o di memoria e possono
inviare/ricevere messaggi DT solamente
tramite entità manager.
Un messaggio Delay Tolerant è inviato da un
entità SAMOA identificata mediante UUID.
Alla creazione di un nuovo messaggio DT
viene specificato il suo TimeToLive (in
millisecondi), alla scadenza del quale il
messaggio viene considerato “scaduto”
(expired). Inoltre in un messaggio DT
possono essere specificati:
 un campo di testo
 un place profile target
 uno user profile target
 un file allegato.
Il messaggio verrà consegnato solamente alle
entità SAMOA presenti in una rete sociale il
4
cui place contiene attività o interessi
specificati nel place profile target, e che
hanno uno user profile che contiene attività o
interessi specificati nello user profile target.
Il servizio è composto da:
 il protocollo DTN per SAMOA e le
primitive di invio/ricezione;
 due pool di threads con rispettive code
di tipo FIFO, uno lato ricezione e uno
lato invio, per la gestione dei messaggi
ricevuti/da inviare;
 la cache, dotata del gestore della
persistenza e del gestore per il
controllo e l’aggiornamento del TTL
dei messaggi memorizzati;
 il gestore dello stato, che si occupa di
mantenere e controllare lo stato dei
messaggi DT inviati alle entità che
sono in prossimità fisica. Inoltre si
occupa di memorizzare lo stato di
ricezione dei files allegati ai messaggi.
Il servizio DTN si interfaccia con:
 il
L/PM,
per
verificare
la
connessione/disconnessione di entità
SAMOA;
 con il MTM, per inviare e ricevere
messaggi secondo il protocollo DTN;
 con il PM, il PSNM e il GSNM, solo
lato manager, per verificare quali
entità fanno parte della rete sociale del
manager e per recuperare gli User
Profile dei client che entrano in
prossimità fisica con il manager;
 con l’SME, solo lato manager, per
effettuare i confronti tra profili di
Place e di User (N.B. gli algoritmi
devono ancora essere implementati, al
momento eseguono un matching che
risulta sempre verificato).
I messaggi Delay Tolerant vengono propagati
in base a interessi e attività specificate,
affinché siano inoltrati e consegnati solo ad
utenti che possano collaborare con l’entità che
ha inizialmente inviato il messaggio.
E’ sempre possibile inviare messaggi DT ad
entità manager che sono in prossimità fisica.
Quando un client entra in prossimità fisica
con un manager gli invia tutti i messaggi DT
che ha memorizzati in cache. Invece il
manager controlla per ogni messaggio DT
memorizzato in cache, se i profili di place e di
user associati al messaggio, matchano
rispettivamente con il proprio profilo di place
e con il profilo di user del client (profilo che
viene ricevuto mediante il servizio di PM). Se
entrambi i profili matchano allora il manager
invia al client il messaggio DT.
Quando due manager entrano in prossimità
fisica si inviano reciprocamente i messaggi
DT che hanno memorizzati in cache.
Quando due client entrano in prossimità fisica
non avviene nessuno scambio di messaggi
DT. Due client non possono inviarsi messaggi
DT in modo diretto, necessitano sempre
dell’intermediazione di un manager.
Quando un manager riceve un messaggio DT
verifica il match dei profili ed eventualmente
inoltra il messaggio al livello applicativo. Poi
invia il messaggio agli altri manager che
sono in prossimità fisica. Infine verifica il
match con i profili dei client presenti nella sua
rete sociale (PSN) ed eventualmente provvede
alla consegna ai client del messaggio appena
ricevuto.
Quando un client riceve un messaggio DT
inoltra sempre il messaggio al livello
applicativo, perché il match dei profili è già
stato eseguito dal manager che gli ha inviato
il messaggio.
E’ possibile allegare un file ad un messaggio
DT. Siccome nelle reti MANET l’evento di
ricezione di pacchetti corrotti è frequente, un
file allegato ad un messaggio DT viene
suddiviso in più parti al fine di non
compromettere l’intera ricezione. Un apposito
handler viene attivato alla ricezione di un
messaggio DT contenente un file allegato.
Successivamente l’handler verifica la corretta
ricezione delle parti del file, richiedendo il reinvio delle parti non ricevute oppure di quelle
parti ricevute che risultano corrotte in seguito
al controllo di ridondanza (CRC). L’invio e la
ricezione delle parti di un file è gestito
mediante una finestra di dimensione
prefissata. La finestra “scorre” solo se la
prima parte del file compresa nella finestra
viene ricevuta in modo corretto. Quando il
file viene completamente ricevuto oppure se il
messaggio DT scade, l’handler termina la sua
esecuzione garantendo la consistenza dello
stato.
5
V – Il protocollo DTN
Il protocollo per l’invio di messaggi DT è
composto dai seguenti sette tipi di messaggi:
 DTDiscoveryMessage, inviato dal
DelayTolerantNetworkManagerConfi
gurationService (descritto in un'altra
relazione) non appena due entità
SAMOA entrano in prossimità fisica.
Contiene un booleano che indica se
l’entità che ha inviato il messaggio è
un manager oppure un client;
 DTRequest, ovvero la richiesta che
precede
l’eventuale
invio
del
messaggio DT. Viene inviata lato
sender e contiene la stringa dell’hash
del messaggio DT che si vuole inviare,
calcolato mediante l’algoritmo MD5;
 DTRequestAcknowledge,
ovvero
l’acknowledge corrispondente ad una
DTRequest. Viene inviato lato
receiver e contiene sia l’hash del
messaggio DT, per il quale era stata
ricevuta la DTRequest, sia un
booleano che indica al sender se
inviare o meno il messaggio (a
seconda che il messaggio sia già stato
ricevuto in precedenza e/o sia già
presente nella cache);
 DTMessage, v. figura 3, ovvero il
messaggio DT vero e proprio.
Contiene il testo del messaggio, il
place profile target, lo user profile
target, il TTL (TimeToLive) espresso
in ms, l’hash del messaggio ed
eventualmente il nome e il path locale
di un file;
 DTMessageAcknowledge,
ovvero
l’acknowledge inviato lato receiver in
seguito alla ricezione di un
DTMessage;
 DTPartOfFile, v. figura 4, ovvero una
parte del file allegato ad un messaggio
DT;
 DTPartsOfFileRequest, ovvero la
richiesta, inviata dal receiver al
sender, dell’invio di alcune parti
mancanti di un file.
Figura 3. Un messaggio DT
Figura 4. Una parte di un file
La sequenza dei messaggi, se
DTRequestAcknowledge ha il flag
send=true, è osservabile nella figura 5.
Figura 5. La sequenza
acknowledge=true
dei
messaggi,
La sequenza dei messaggi, se
DTRequestAcknowledge ha il flag
send=false, è osservabile nella figura 6.
Figura 6. La sequenza
acknowledge=false
dei
messaggi,
il
di
con
il
di
con
Siccome i messaggi sono inviati mediante
primitive asincrone non reliable, è presente
un oggetto che svolge la funzione di
6
controller dello stato ed effettua il re-invio dei
messaggi che non arrivano a destinazione al
fine di garantire la reliability.
La ricezione di messaggi del protocollo DTN
avviene mediante una InputPort messa a
disposizione dal MTM.
Alla ricezione di un messaggio DT,
quest’ultimo viene inserito nella coda FIFO
dei messaggi ricevuti. In questo modo il
servizio non viene bloccato ed è pronto per
ricevere un nuovo messaggio. Uno dei threads
del pool di ricezione andrà poi a prelevare il
messaggio inserito e ad eseguire il codice
necessario.
Se il messaggio è un DTMessage e i match
dei profili sono stati positivi, allora il livello
applicativo viene notificato della ricezione del
messaggio.
L’invio di messaggi secondo il protocollo
DTN avviene mediante una OutputPort messa
a disposizione dal MTM.
Un messaggio da inviare viene inserito in una
coda FIFO e viene poi prelevato da uno dei
threads del pool di invio. Il thread gestirà
l’invio del messaggio all’entità SAMOA
destinataria.
VI – Le primitive di comunicazione
La comunicazione tra i servizi DTN di due
entità SAMOA avviene sempre mediante la
modalità punto-a-punto.
Le primitive di comunicazione del DTN
Service sono di tipo asincrono, asimmetrico,
non bloccante, non reliable.
L’invio e la ricezione di messaggi secondo il
protocollo DTN sono delegati a due pool di
threads, uno per l’invio e l’altro per la
ricezione, i cui threads sono allocati
staticamente. E’ stata fatta questa scelta per
limitare l’utilizzo della memoria da parte
della JVM, che, nel caso di numerosi
messaggi da inviare/ricevere, crescerebbe
senza controllo, occupando la memoria fisica
disponibile.
Grazie al meccanismo della delega per l’invio
e la ricezione dei messaggi, il servizio DTN è
libero di eseguire le funzionalità di controllo e
gestione senza venire interrotto.
Le primitive di invio messe a disposizione dal
servizio DTN per SAMOA sono le seguenti:
VII – Casi di studio
Il servizio di DTN per SAMOA è stato testato
in una rete locale. Abbiamo impiegato quattro
PC, due che hanno ricoperto il ruolo di
manager e gli altri due che hanno ricoperto il
ruolo di client. I profili delle entità sono stati
scelti in modo che ogni client ha un profilo
compatibile solamente con uno dei due
manager.
Lo scopo del primo caso di studio è stato
quello di verificare che un messaggio DT
inviato da un client viene consegnato all’altro
client mediante il forwarding eseguito dai
manager. Si sono inizialmente considerate le
entità disconnesse, quindi non in prossimità
fisica. Il client “sender” verifica la presenza
di eventuali manager in prossimità fisica, ma
essendo isolato memorizza nella cache il
messaggio DT, con un file allegato, che
intende inviare. Quando un manager viene
connesso alla LAN, il client gli invia il
messaggio DT. Una volta che anche l’altro
manager si connette, riceve il messaggio DT o
dall’altro manager mediante forwarding
oppure dal client che ha inizialmente inviato il
 public void sendDTMessage
(DTMessage message,UUID toID,boolean
deleteAfterSend): questa primitiva copia in
cache il messaggio DT passato come
argomento e invia al destinatario toID la
DTRequest corrispondente al message. Il
messaggio viene eventualmente cancellato
dalla
cache
a
seconda
del
flag
deleteAfterSend;
 public void sendDTMessage
(DTMessage message,UUID toID): questa
primitiva copia in cache il messaggio DT
passato come argomento e invia al
destinatario
toID
la
DTRequest
corrispondente al message. La cancellazione
del messaggio dalla cache dopo l’invio è
gestita dalla politica di default specificata nel
file di configurazione SamoaOptions.
7
messaggio. Infine una volta che anche l’altro
client si connette alla rete, dopo che entra a
far parte della Social Network del manager
con cui ha il profilo compatibile, riceve dal
manager il messaggio inizialmente inviato
dall’altro
client.
Abbiamo
simulato
disconnessioni temporanee tra le entità e
abbiamo verificato che, grazie al gestore dello
stato,
la
comunicazione
riprende
correttamente se la disconnessione è avvenuta
entro i timeout impostati. Se scade il timeout
relativo alla sequenza di figura 5, la
comunicazione ricomincia dall’inizio. Anche
se scade il timeout dell’handler del file, il file
temporaneo e il messaggio DT vengono
cancellati
e
l’interazione
comincia
nuovamente. In un caso o nell’altro la
consistenza dello stato del sistema è
comunque garantita. La velocità di
trasmissione nell’invio di un file allegato è di
circa 40 KB/s e abbiamo notato che è
notevolmente influenzata dalla ricezione di
numerose parti che risultano corrotte,
probabilmente
a
causa
di
un
malfunzionamento del Message Transport
Manager.
Abbiamo poi testato il DTN Service per
SAMOA “a regime”, ovvero con tutte le
quattro entità connesse contemporaneamente.
Abbiamo visto che il sistema ha supportato
discretamente il carico di messaggi DT
inviato. Nel momento in cui due o più entità
entrano in prossimità fisica, ovvero vengono
connesse, e effettuano allo stesso tempo le
operazioni e le comunicazioni per la gestione
del contesto e quelle per il forwarding di
messaggi DT, si verifica che alcuni messaggi
non arrivano a destinazione oppure subiscono
ritardi.
Abbiamo infine effettuato un controllo sulle
prestazioni, verificando che circa 40-45
threads sono sempre attivi durante
l’esecuzione in ogni entità. La memoria nonheap occupata è costante ed è di circa 15 MB.
Invece la memoria heap che viene utilizzata
varia a seconda del carico di lavoro, fino a
picchi di 70-80 MB nei momenti di maggior
carico. Ciò può rappresentare un problema per
dispositivi portatili con scarse risorse
computazionali e/o di memoria, che
evidentemente non possono ricoprire il ruolo
di manager.
VIII – Conclusioni e sviluppi futuri
Grazie allo sviluppo del servizio di Delay
Tolerant Networking, il middleware SAMOA
mette ora a disposizione ulteriori funzionalità
per operare in scenari dove le entità possono
comunicare anche se non sono connesse in
modo diretto. Ciò ha permesso a SAMOA di
acquisire una maggiore flessibilità e
dinamicità con la possibilità di favorire il suo
utilizzo nello sviluppo di servizi collaborativi
basati sul contesto e sul matching semantico.
Il supporto può essere utilizzato per risolvere
problemi diversi, lasciando così liberi gli
sviluppatori di concentrarsi sulla logica
applicativa.
SAMOA è però un software platformdependent per cui in futuro potrebbero essere
sviluppati meccanismi per l’integrazione con
altri linguaggi di programmazione.
E’ inoltre necessario sviluppare opportuni
algoritmi di matching per poter confrontare i
profili specificati in un messaggio DT con i
profili di manager e client, al fine di sfruttare
pienamente le funzionalità del DTN Service.
Bibliografia
[1] Dario Bottazzi, Rebecca Montanari,
Alessandra Toninelli, A Semantic Contextaware Middleware-level Solution to Support
Anytime and Anywhere Social Networks,
IEEE Intelligent Systems - Special issue on
Social Computing, IEEE, September-October
– 2007
[2] Kevin Fall, A Delay-Tolerant Network
Architecture for Challenged Internets
8