Presentazione di
Francesco Fiori
Reti di Calcolatori LS
Professor Antonio Corradi
Ingegner Dario Bottazzi
Il progetto si è concentrato sull’adattamento del
framework SAMOA a scenari di emergenza dove la priorità
è la comunicazione tra persone in difficoltà e la rapida
disseminazione di informazioni nonostante le possibili
carenze di infrastrutture per la comunicazione.
Il lavoro svolto verte sullo sviluppo di un servizio per
favorire la comunicazione sia sincrona che asincrona tra
utenti appartenenti a reti sociali differenti oppure non
direttamente connessi in quanto in una situazione di
emergenza è possibile che un singolo nodo rimanga isolato
per un tempo prolungato.
• Socially Aware and
MObile Architecture (SAMOA) è
un middleware che integra un insieme di facilities per
la gestione, la personalizzazione e la propagazione di
una rete sociale a livello applicativo
• SAMOA supporta la creazione di reti sociali
semantiche context-aware tra utenti fisicamente
vicini, con stesse attitudini e interessi
• La rete sociale è centrata sull'utente e utilizza due
tipologie di visibilità di contesto:
• Place visibility
• Profile visibility
• Manager: utenti interessati a
creare una propria rete sociale,
hanno la responsabilità di
definire i confini della località
e scegliere i criteri sui
partecipanti
• Client: tutti gli utenti presenti
all'interno dei confini stabiliti
dal manager, sono i candidati a
diventare i membri della rete
sociale
• Member: sono i client che
entrano a far parte di una rete
sociale
• Social Network Management Layer: fornisce meccanismi per l'estrazione
della rete sociale e per la sua gestione
• 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
• DTN Layer: fornisce il servizio per la gestione di messaggi Delay Tolerant
inviati a entità SAMOA non necessariamente connesse in modo diretto
Durante una situazione di emergenza ci sono tre problematiche da affrontare:
•
Tecnologiche: difficoltà nell'implementare gli adeguati sistemi di comunic
azione
• Sociologiche: devono comunicare gruppi di persone eterogenee
• Organizzative: difficoltà nella gestione di molte informazioni imprecise
Possibile soluzione? La creazione di reti sociali contexaware
tra utenti fisicamente vicini per una rapida diffusione delle
informazioni -> Utilizzo del framework SAMOA
Ulteriore problematica: possibilità che nodi della rete sociale rimangano
isolati per un periodo di tempo prolungato
Possibile soluzione? Implementazione di un servizio aggiuntivo che
permetta di inviare messaggi tra entità non direttamente connesse tramite
un meccanismo di forwarding -> DTN Architecture
• La DTN Architecture si propone come obiettivo la possibilità
di far comunicare tra loro reti indipendenti, mutuamente
incompatibili caratterizzate da ritardi di trasmissione molto
variabili, da periodi di perdita delle connessioni di durata
arbitrariamente lunga, da alti tassi di errore e da forte
asimmetria di trasmissione dei dati nelle due direzioni.
• Fornisce servizi chiave come la memorizzazione, la
ritrasmissione e il forwarding di messaggi asincroni al fine di
garantire l’affidabilità alla comunicazione
• Si basa su due concetti fondamentali:
regione: parte della rete globale che comprende uno o più nodi
gateway: nodo con elevate capacità computazionali che ha il compito di gestire i
messaggi che riceve da altri nodi e di forwardarli
• Il DTN Layer che abbiamo aggiunto all'architettura è
un'estensione di SAMOA, è stato quindi necessario mappare le
strutture tipiche della DTN Architecture con quelle del
middleware:
DTN Architecture
DTN Service
Regione: parte della rete globale che
comprende uno o più nodi
Place-depent Social Network: gli utenti
della regione saranno gestiti tramite il
PSNM
Gateway: nodo con elevate capacità
computazionali che ha il compito di
gestire i messaggi ricevuti da altri nodi e
di effettuarne il forwarding
Manager (sarà anche forwarder): nodo
della rete responsabile della
memorizzazione dei messaggi DT e del
forwarding dei messaggi memorizzati
nella cache ai nodi con cui entra in
prossimità fisica
• Protocollo DTN: comprende tutte le primitive di invio e ricezione
dei messaggi DT
• Un pool di thread per gestire l'invio dei messaggi DT e la
ritrasmissione di pacchetti non giunti a destinazione
• Un pool di thread per gestire la ricezione dei messaggi DT e le
richieste in caso di errore
• Una cache: un database all'interno del quale vengono
memorizzati i messaggi DT. Ha anche il compito di aggiornare il
TTL di ogni messaggio, provvedendo alla cancellazione dei
messaggi scaduti
• Un gestore dello stato per gestire lo stato del protocollo DTN e lo
stato del protocollo di scambio File
• Il DTN Service si occupa dell’invio/ricezione di messaggi DT
• I DT messages vengono memorizzati in una cache per
forwarding futuri anche dopo un certo periodo di tempo
• I ruoli all’interno del DTN Service sono 3:
• sender (sia client che manager)
• receiver (sia client che manager)
• forwarder (solo manager)
• I messaggi DT vengono scambiati in base alla selezione del
profilo dei destinatari, ci sono due differenti livelli di profilo
specificabili dal sender del messaggio:
• Place Profile Target (PP)
• User Profile Target (UP)
• Quando un client entra in prossimità fisica con un manager gli
invia tutti i messaggi DT che ha memorizzato in cache
• Quando due manager entrano in prossimità fisica si inviano
reciprocamente i messaggi DT che hanno memorizzato in cache
• Quando due client entrano in prossimità fisica non avviene
nessuno scambio di messaggi DT. Due client 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 proprio
livello applicativo. Successivamente invia il messaggio agli altri
manager. 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.
• La cache è stata realizzata su un database db4o (DataBase For
Objects), un database a oggetti open source su file facilmente
integrabile con Java
• Tutti i messaggi, sia inviati che ricevuti, sia che si tratti di client
che di manager, vengono salvati in cache
• I messaggi devono essere serializzati per essere inseriti in
cache e deserializzati per esser letti e modificati
• Per rendere più leggero l’accesso alla cache i file allegati
vengono salvati esternamente su disco visto che db4o non è
adatto a grosse mole di dati
Record della cache
messageHash
dtnMessageBytes
readable
deleteAfterSend
• Oltre al campo messaggio, ogni tupla del database
contiene altri campi necessari alla gestione:
• message hash
• la flag readable
• la flag deleteAfterSend
• thread TTLController: serve per controllare il time to
live di tutti i messaggi presenti in cache, è un thread
che viene fatto partire dal costruttore della classe
DTNMCache e può esserne specificato l'intervallo tra
un controllo e l'altro
I test sono stati eseguiti su una rete locale utilizzando
quattro computer: 2 manager e 2 client
Test di forwarding:
solo 2 entità connesse alla volta
-> test positivo
Test di carico elevato:
tutte e 4 le entità connesse
Contemporaneamente
-> qualche malfunzionamento
Aspetti negativi sorti dai test:
• bassa velocità di scambio file allegati di grosse dimensioni
(troppi pacchetti persi)
• problemi di gestione vari (failure bizantine) nel test con
tutte e 4 le entità connesse
• discordanze di TTL tra le varie entità: possibili forwarding
per messaggi già ricevuti o scaduti
Aspetti positivi:
• possibilità di comunicazione asincrona
• possibilità di utilizzare SAMOA anche in scenari di
emergenza grazie alla nuove caratteristiche
•SAMOA ha acquisito maggiore affidabilità e dinamicità
• recoverability e reability: consistenza del sistema grazie a
un buon utilizzo degli stati anche in caso di disconnessioni
temporanee