relazione

PERMESSO
PERsistent MESSagging in ad hOc networks
Melli Michele
Sommario
Il progetto mira allo sviluppo di un servizio di messaggistica
istantanea per dispositivi portatili, come laptop, PDA o smart phone
connessi ad una MANET (Mobile Ad hoc NETwork). In questa
relazione si discuterà del modello di comunicazione messo a
disposizione da PERMESSO ad un utente che desideri inviare un
messaggio ad un destinatario al momento disconnesso
(messaggistica asicrona). In particolar modo si analizzerà il caso in
cui nella rete è presente un dispositivo che fornisce funzioni di
supporto a questo tipo di comunicazione (Persistent Server).
1. Introduzione
Le Mobile ad hoc networks (MANETs) rappresentano sistemi distribuiti complessi in cui
dispositivi mobili possono liberamente organizzarsi in arbitrarie e temporanee topologie di
rete “ad-hoc”, fornendo alle persone e ai dispositivi la percezione di operare collegati con
altri dispositivi o persone in aree in cui non esistono infrastrutture fisse di comunicazione.
Considerando l’instabilità dei canali di comunicazione wireless e le possibilità di
movimento degli utenti, tali reti risultano estremamente dinamiche. In questa topologia di
architettura devono essere rivalutate la semantica e le proprietà della comunicazione, in
quanto inevitabilmente si tratta di sistemi orientati a dinamiche di tipo best-effort in cui
sono frequenti le perdite di messaggi e le cadute temporanee dei nodi. I vantaggi introdotti
dalle MANETs sono tuttavia notevoli perché forniscono caratteristiche non ottenibili dalle
reti “classiche” come la proprietà di non richiedere alcun server centrale, né cablaggi di
cavi o access point.
Per realizzare PERMESSO si è utilizzato una Java Virtual Machine ridotta (J2ME) con la
configurazione minima (CLDC 1.0 e MIDP 2.0) adatta a dispositivi mobili e con capacità
computazionali e di memorizzazione limitate.
Questa scelta di progetto ha portato a dover implementare funzionalità come la
serializzazione dei dati da inviare e il supporto dell’affidabilità visto che l’unico protocollo di
trasporto messo a disposizione dall’ambiente di sviluppo è l’invio di pacchetti UDP.
Si è supposto che tutti i nodi appartenenti alla Manet siano a distanza 1-hop e che ci sia
reciproca visibilità tra i partecipanti.
La comunicazione tra i dispositivi avviene tramite l’interfaccia wireless 802.11.
2. PERMESSO
Il progetto è articolato in tre moduli:
DISCOVERY: Si occupa di gestire l’ingresso e l’uscita dalla chat di un utente e di
comunicare questo evento agli altri partecipanti. Il discovery è realizzato da un
Primary Master che, una volta intercettato il messaggio d’ingresso inviato in broadcast
dal nuovo entrato, aggiorna la sua lista dei nodi online e periodicamente la invia a tutti
i partecipanti, stessa cosa accade per l’uscita. Inoltre si occupa di controllare se
qualche nodo è caduto o uscito dal range di copertura della MANET abbandonando
quindi il sistema senza avvisare. Il ruolo di Primary Master può essere ricoperto da un
qualunque partecipante alla chat; per non caricare a lungo un singolo nodo si è deciso
di far ruotare il ruolo fra i presenti. Per far fronte all’ipotesi di guasto singolo si è deciso
di replicare questo ruolo nominando un Secondary Master.
CHAT SINCRONA: Fornisce le funzionalità di messagistica istantanea tra due utenti
appartenenti alla stessa MANET. Ricevuta la lista dei nodi online, un utente identifica
tra questi i nodi “amici” (la relazione di amicizia è considerata biunivoca) con i quali,
dopo avere effettuato un protocollo di hand-shaking, può scambiare messaggi di testo.
Gestisce inoltre la possibilità di effettuare più comunicazione sincrone
contemporaneamente.
Per garantire la reliability del servizio è prevista la
ritrasmissione dei messaggi persi. Si è scelto di ricorrere all’utilizzo del cumulative ack
in quanto, visto il notevole numero di messaggi che vengono trasmessi con questo
servizio, garantisce un minor overhead rispetto al single ack.
CHAT ASINCRONA: Gestisce il caso in cui si vuole inviare un messaggio ad un
utente che in quel momento non è connesso alla MANET. Per questo servizio sono
previste due modalità di funzionamento:
 La prima prevede la presenza di un nodo particolare, chiamato Persistent
Server, che si occupa di raccogliere i messaggi asincroni e di recapitarli ai
destinatari quando entrano nella MANET.
 La seconda prevede la memorizzazione dei messaggi asincroni da parte del
mittente in attesa dell’ingresso del destinatario. Se il mittente decide di uscire
dalla chat o finisce lo spazio di memoria disponibile (abbiamo a che fare con
dispositivi con capacità di memorizzazione limitate) esegue un algoritmo di
elezione per trovare un nodo adatto a cui affidare i messaggi.
3. Servizio di Chatting Asincrono
3.1 Persistent Server
Il Persistent Server non è stato implementato come un dispositivo dedicato solo alla
ricezione, alla memorizzazione e al delivery dei messaggi asincroni. E’ stata prevista
un’unica tipologia di dispositivo e la possibilità di attivare un flag che condiziona il
funzionamento del nodo in varie fasi . Quando entra un nuovo utente il Persistent Server
dovrà avvisarlo della sua presenza e inviare eventuali messaggi asincroni a lui destinati. A
differenza degli altri nodi il Persistent Server attiva un thread in più (il Persistent Thread)
che si occupa di ricevere su una porta dedicata tutti i messaggi asincroni inviati all’interno
della rete. L’utente che utilizza il dispositivo scelto per il ruolo di Persistent Server sarà
quindi in grado di usufruire dei servizi di chatting sincrono e asincrono; a differenza degli
altri utenti non spedirà i messaggi asincroni ma li memorizzerà in locale. Si è fatta l’ipotesi
che il Persistent Server abbia una capacità di memorizzazione superiore rispetto gli altri
nodi, per questo non è stata imposta nessuna limitazione sul numero di messaggi che il
dispositivo è in grado di memorizzare.
3.2 Percezione della presenza del Persistent Server
Un nodo che desidera entrare nel sistema come prima cosa invia in broadcast un
messaggio di tipo ENTERED. Questo messaggio non serve solamente al servizio di
discovery ma viene intercettato anche dal Persistent Server il quale dovrà comunicare al
nuovo entrato la sua presenza. Questo avviene inviando un messaggio di tipo
PERSISTENT al nodo entrato il quale setta a true un boolean di presenza del Persistent
Server che condizionerà il comportamento durante l’invio di messaggi asincroni. Dal
messaggio viene inoltre estratto l’ip del nodo Persistent Server.
Sia il messaggio ENTERED sia quello PERSISTENT vengono inviati sulla MAIN_PORT
usata per il discovery e vengono gestiti in ingresso da un dispatcher thread.
Fig.1: Protocollo per la percezione
della presenza del Persistent Server
Si è scelto di utilizzare questo semplice protocollo per non caricare ulteriormente la fase di
discovery nella quale il dispositivo riceve e invia un gran numero di messaggi. La fase che
fornisce la percezione della presenza del Persistent Server necessita però di maggior
affidabilità visto che è fondamentale per il corretto funzionamento del servizio di chatting
asincrono. Si è quindi deciso di inserire un successivo controllo sulla presenza del
Persistent Server : se il nodo client, terminato il protocollo illustrato in precedenza, non
riceve nessun messaggio dal Persistent Server, invia un messaggio in broadcast del tipo
PERSISTENT REQ e attiva un thread (Persistent Presence Thread) incaricato di ricevere
eventuali risposte su una porta dedicata (PERSISTENT CONFIRM PORT) diversa dalla
MAIN PORT notevolmente congestionata dai messaggi utilizzati per il discovery. Il
messaggio PERSISTENT REQ viene mandato verso la ASYNC PORT sulla quale il
Persistent Thread del server è in ascolto per ricevere i messaggi asincroni. La risposta di
conferma è un messaggio del tipo PERSISTENT come quello visto in precedenza che fa
terminare il Persistent Presence Thread e rende cosciente il nodo della presenza del
Persistent Server e di come raggiungerlo.
Fig.2: Secondo protocollo per la percezione
della presenza del Persistent Server
Nel caso in cui il Persistent Server non sia presente all’interno della rete e quindi non
possa rispondere al Persistent Presence Thread, e stato predisposto un timeout dopo il
quale il thread termina e il dispositivo si rende conto di essere in una situazione in cui i
nodi devono gestire autonomamente il servizio di chatting asincrono.
Nella realizzazione di questa funzionalità si sono riscontrate alcune complicazioni in
quanto la versione della J2ME utilizzata non prevedeva il timeout sulla connessione. Si è
quindi pensato di utilizzare un thread separato (Killer Thread) che ha il compito di forzare
l’uscita dalla receive che altrimenti risulterebbe bloccante per il Persistent Presence
Thread.
Fig.3: Secondo protocollo: caso senza
Persistent Server
3.3 Invio lato Client e ricezione lato Server di messaggi asincroni
L’utente che vuole mandare un messaggio asincrono per prima cosa seleziona dalla lista
degli utenti amici il destinatario, poi scrive il testo in una Chat Form. La form è dello stesso
tipo quella utilizzata per il servizio sincrono ma in questo caso prima dell’apertura non si
effettua il protocollo di hand-shaking (v. relazione di Bonsi Valentina). Il messaggio (di tipo
ASYNC MESS) viene spedito verso l’ ASYNC PORT del Persistent Server.
Da notare la differenza tra l’indirizzo del destinatario della datagram UDP (usato per
recapitare il messaggio al Persistent Server) e il campo receiver inserito all’interno del
messaggio (usato dal Persistent Server per effettuare il successivo delivery al destinatario
finale).
Fig.4: Interfaccia grafica per l’invio di
messaggi asincroni
Lato server il Persistent Thread è sempre in ascolto e appena riceve un messaggio
ASYNC MESS lo salva in memoria.
Il mittente numera i messaggi di ogni singola sessione di comunicazione asincrona in
modo crescente. Il destinatario finale ad ogni ricezione ridisegna la Chat Form inserendo i
messaggi nell’ordine corretto. Ci si può trovare quindi in una situazione in cui al
destinatario viene temporaneamente visualizzato un messaggio nonostante non sia
ancora arrivato un’altro che lo precede. Questa situazione avviene raramente poiché il
Persistent Server invia i messaggi in modo ordinato; può comunque accadere che un
messaggio vada perso e che la ritrasmissione avvenga in un secondo momento.
Un ordinamento FIFO è più che sufficiente in questo caso, non è necessario ricorrere
all’utilizzo di timestamp fisici o logici in quanto dobbiamo ordinare messaggi provenienti da
un unico mittente e che non hanno tra loro una relazione di tipo causale.
3.4 Delivering dei messaggi asincroni
Un nodo, terminata la fase di discovery, come prima cosa chiede al Persistent Server se
ha in memoria messaggi asincroni per lui mandando sulla MAIN PORT un messaggio del
tipo ASYNC REQ dal quale il server estrae l’identificatore univoco del nodo e lo utilizza
per avviare una ricerca in memoria. Se trova messaggi asincroni indirizzati al nodo, li
spedisce e avvia un thread per garantire affidabilità al servizio; questo argomento verrà
trattato nel paragrafo seguente. Il protocollo di richiesta di messaggi asincroni è lo stesso
anche nel caso in cui non è presente il Persistent Server, cambierà solamente l’indirizzo
del messaggio ASYNC REQ che invece di avere un singolo destinatario sarà spedito in
broadcast a tutti i partecipanti alla MANET.
I messaggi asincroni spediti dal Persistent Server vengono visualizzati sul dispositivo nelle
stesse Chat Form utilizzate per il servizio sincrono e per l’invio dei messaggi asincroni
(viene creata una form diversa per i messaggi provenienti dallo stesso mittente). Se colui
che ha inviato il messaggio asincrono è online è possibile fare uno switch tra le due
modalità di comunicazione effettuando lo stesso protocollo di hand-shaking usato per
iniziare una sessione sincrona.
3.5 Reliability
Utilizzando il protocollo UDP per l’invio dei messaggi è stato necessario aggiungere un
controllo a livello applicativo sulla corretta ricezione per garantire maggiore affidabilità.
Sono state prese in considerazione due possibilità: il cumulative ack e il single ack. La
prima è stata scartata in quanto, a differenza del caso sincrono, le singole sessioni di
comunicazione asincrona sono composte da pochi messaggi . Si è optato per l’utilizzo del
single ack che comporta si un overhead maggior rispetto al cumulative ack, ma tuttavia
accettabile.
Quando il Persistent Server termina di inviare i messaggi asincroni spediti ad un nodo
durante la sua assenza, avvia un thread (Ack Controller) al quale delega il compito di
controllare periodicamente se ad ogni messaggio appartenente al vettore
sentAsyncMessages, corrisponde un messaggio di ack nel vettore receivedAsyncAck.
All’ Ack Controller viene inoltre delegata la ritrasmissione dei messaggi per i quali non è
stata trovata la corrispondenza nei due vettori. C’è da sottolineare che viene creato un Ack
Controller per ogni destinatario dei messaggi asincroni, ricevuti tutti gli ack il thread
termina e cancella dalla memoria i due vettori. La ricezione degli ASYNC ACK e
l’inserimento all’interno del vettore receivedAsyncAck è a carico del Persistent Thread
perennemente in ascolto sulla ASYNC PORT.
La ritrasmissione dei messaggi da parte del Persistent Server può avere quindi due
possibili cause: la perdita del messaggio asincrono o la perdita dell’ack.
Fig.5: Protocollo di reliability
3.6 Ingresso del Persistent Server
Le specifiche di progetto indicavano di considerare il Persistent Server come un
dispositivo costantemente presente all’interno della MANET. Si è deciso di introdurre
un’estensione che prevede la possibilità per il Persistent Server di entrare nella rete anche
quando il sistema è già in funzione e una serie di nodi stanno gestendo in modo autonomo
il servizio di chatting asincrono.
Il Persistent Server, in modo analogo a tutti gli altri nodi, appena entra nella MANET invia
in broadcast l’ENTERED. Questo messaggio contiene le informazioni che identificano un
nodo, compreso un boolean che indica se ricopre il ruolo di Persistent Server. Quando i
partecipanti alla rete ricevono questo messaggio si rendono conto che è cambiata la
politica di gestione della comunicazione asincrona e avviano una procedura di
svuotamento delle memorie locali inviando al Persistent Server sia i messaggi asincroni
spediti dal nodo stesso sia quelli che mantenevano per conto di altri utenti che avevano
finito lo spazio di memorizzazione disponibile o che avevano abbandonato la rete (v.
relazione di Vitalone Giuseppe).
Si ricorda che il Persistent Server può usufruire degli stessi servizi di un nodo normale e
quindi anche della comunicazione asincrona. I messaggi asincroni indirizzati all’utente che
utilizza il Persistent Server, quindi da visualizzare, saranno mandati verso la MAIN PORT,
quelli da memorizzare in vista di un successivo delivery verso la ASYNC PORT.
4. Conclusioni e sviluppi futuri
Possiamo concludere che PERMESSO soddisfa a pieno le specifiche richieste: offre un
servizio di chatting istantanea, persistente e affidabile nonostante i limiti del canale di
trasmissione utilizzato. Il sistema presenta però limiti alla scalabilità visto l’elevato numero
di messaggi scambiati durante la fase di discovery che introducono ritardi nella
comunicazione.
Per quanto riguarda la comunicazione asincrona si fornisce trasparenza all’utente sulla
presenza o meno del Persistent Server.
L’utilizzo del Persistent Server evita l’eventuale perdita di messaggi asincroni dovuta alla
limitata capacità di memorizzazione di dispositivi portatili come PDA o smart phone, ha
comunque il limite di non prevedere la replicazione del ruolo e di non essere quindi
tollerante a guasti. Una possibile estensione potrebbe essere appunto l’introduzione del
monitoraggio dello stato del Persistent Server da parte degli altri nodi e la replicazione del
ruolo in caso di guasto.
Per garantire maggior scalabilità si potrebbe modificare l’architettura del sistema
suddividendo verticalmente la MANET e introducendo il ruolo di coordinatore in ogni
partizione, così facendo si ridurrebbe l’overhead dovuto al servizio di discovery.
PERMESSO è stato progettato per essere utilizzato in zone come campus universitari o
sale d’attesa di aeroporti, un possibile sviluppo futuro potrebbe prevedere l’introduzione di
servizi di news con la possibilità di registrazione da parte degli utenti interessati (ad
esempio comunicazioni di servizio di facoltà o avvisi riguardanti specifici corsi di laurea).
Bibliografia
[1] I. Chlamtac, M. Conti, JJN Li, “Mobile ad hoc networking: imperatives and challenger”, Elsevier
Journal of Ad Hoc Networks, vol.1, no.1, 2003.
[2] K. Topley, “J2ME in a nutshell”, O’Reilly, 2002.
[3] J. F. Kurose, K. W. Ross, “Internet e reti di calcolatori”, seconda edizione, McGraw-Hill, 2003.
[4] A.S. Tanenbaum, M. van Steen, “Distributed Systems: principles and paradigms”, Prentice-Hall,
2002.
[5] A. Corradi, Slides del Corso di Reti di Calcolatori L-S e L-A