relazione - Università di Bologna

Permesso (PERsistent MESSagging in ad hOc networks)
Vittoria Caranna – matr.0000230660
C.d.L.S Ingegneria Informatica
Università di Bologna
Reti di Calcolatori LS – Prof. Antonio Corradi – A.A 2005/06
Referente progetto: Eugenio Magistretti
Bologna, 30-01-2007
Abstract
Le reti MANET (Mobile ad hoc Networks)
sono piccole reti che permettono di
connettere dispositivi portatili come laptop,
PDA o smart phones e sembrano
particolarmente interessanti per permettere
l’elaborazione in contesti difficili o
addirittura ostili in cui non è possibile avere
un’infrastruttura di comunicazione fissa.
Il progetto PERMESSO si propone di
realizzare un servizio di messaggistica
istantanea in cui la mancanza di nodi fissi
determina la necessità di ripensare alla
realizzazione delle funzionalità di base, come
le politiche d’instradamento dei messaggi,
che coinvolgono i nodi stessi.
Introduzione
La Mobile Ad Hoc NETworks (MANET) è
un insieme di host forniti di interfaccia di rete
wireless che formano una rete senza l’aiuto di
una infrastruttura fissa e senza la necessità di
un’amministrazione centralizzata.
Per loro natura le reti ad hoc sono la
soluzione ideale per tutti quei casi in cui le
infrastrutture di comunicazione esistenti non
sono disponibili, non sono affidabili o più
semplicemente troppo costose da realizzare.
Il progetto PERsistent MESSagging in ad
hOc networks (PERMESSO) mira a fornire
agli utenti un servizio di messaggistica
istantanea,
proponendo modelli di
comunicazione sincrona ed asincrona.
Le comunicazioni, così come le politiche
di instradamento, sono a carico dei singoli
nodi terminali. I nodi appartenenti alla rete
hanno la possibilità di entrare ed uscire dalla
rete liberamente.
I tipi di comunicazione che possono essere
intrapresi sono di due tipologie:
 sincrona quando entrambi gli
interessati allo scambio di messaggi
sono presenti nella rete
 asincrona quando uno dei due
nodi
interessati
non
è
momentaneamente presente nella rete.
In questo ultimo caso occorre un
meccanismo che permetta di memorizzare
temporaneamente il messaggio e di
recapitarlo non appena il destinatario entra
nella rete MANET. A tal proposito, il
progetto
PERMESSO
prevede
la
realizzazione e la gestione di un server che si
fa carico di tali responsabilità. La
comunicazione asincrona è prevista anche in
assenza del server, lasciando il compito di
memorizzazione e delivery dei messaggi ad
un nodo scelto all’interno delle rete.
Nel seguito verrà trattato il servizio di
chatting asincrono, previsto secondo le due
modalità menzionate. Si tratteranno le
problematiche di comunicazione con server e
con nodo scelto, sarà presente una sezione
dedicata alla gestione della qualità di servizio
e a seguire una sezione dedicata agli sviluppi
futuri e alle conclusioni.
1
1.Architettura generale
La caratteristica interessante di questa
tipologia di rete ad-hoc è che tutti i nodi che
fanno parte della rete cooperano tra di loro
per lo scambio delle informazioni.
Considerando una visione a strati
dell’architettura del sistema, il livello più alto
è occupato dal client e dall’eventuale server.
Il client è un host presente all’interno
dell’ambiente di riferimento che nel nostro
caso è la MANET. I partecipanti della rete
possono essere dispositivi portatili come
laptop, PDA o smart phones. Gli host sono
mobili, possono entrare ed uscire dalla rete
liberamente e sono connessi in modo
intermittente attraverso un’alta variabilità di
collegamenti e in un ambiente fortemente
dinamico. I dispositivi il più delle volte hanno
capacità limitate, come CPU lente, piccole
quantità di memoria, schermi ridotte e così
via. Tutte queste caratteristiche influiscono
sulla gestione delle comunicazioni.
I servizi di cui un client può usufruire
all’interno di una MANET sono:
 comunicazione con uno degli
amici presenti in rubrica
 aggiunta di
altri amici
effettuando una ricerca per alias tra gli
host presenti nella rete

comunicazione in modalità
sincrona se il destinatario dei suoi
messaggi è on-line

comunicazione in modalità
asincrona. In tal caso si deve ricorrere
all’utilizzo di altre entità presenti nella
rete.
La comunicazione asincrona può avvenire
mediante la presenza di un server o di un
eventuale nodo scelto all’interno della rete
stessa.
Il server è una entità capace di funzionare
per uno scopo specifico. Dal punto di vista del
client, se esso è presente, rappresenta un
punto di riferimento a cui viene delegato il
compito di inoltrare i messaggi asincroni cioè
messaggi inviati da un mittente ad un
destinatario che al momento dell’invio è
offline.
I servizi che il server mette a disposizione
degli host all’interno della rete sono:
 memorizzazione dei messaggi
pendenti per un host
 delivery dei messaggi asincroni
all’ingresso del destinatario all’interno
della rete
Le caratteristiche del server permettono di
esplicare tali funzionalità e di venire incontro
alle esigenze degli host della rete. Esso dovrà
avere inoltre la possibilità di conoscere i
partecipanti all’interno della rete per poter
mantenere la corrispondenza tra mittente e
destinatario dei messaggi che viaggiano
all’interno della rete.
In assenza del server, è previsto un
ulteriore ruolo all’interno della MANET che è
quello di un nodo scelto. Questo viene
incontro al fatto che un utente, che ha in
memoria dei messaggi per utenti offline,
potrebbe decidere di abbandonare la rete da
un momento all’altro. Per evitare di perdere i
messaggi, indica in maniera proattiva la
propria intenzione a lasciare la rete,
consentendo l’invio dei messaggi a nodi terzi
( nodo scelto).
Il nodo scelto all’interno della rete viene a
sostituire, in un certo senso, la presenza del
server. La differenza principale è che in tal
caso occorrerà tener conto di tutte le
problematiche insite nelle caratteristiche di un
nodo che a differenza del server avrà capacità
di memoria limitate, bassa capacità
computazionale.
I servizi offerti dal nodo scelto sono
sempre quelli di mantenere in memoria i
messaggi per nodi offline e di effettuare il
delivery all’ingresso di un nodo nella rete
MANET.
1.1 Caratteristiche architetturali
Per avere una maggiore chiarezza sui
concetti e termini che verranno utilizzati
successivamente, occorre dare una semplice
descrizione di questi.
Il progetto parte dalla realizzazione di
pacchetti che vengono scambiati tra i nodi
della rete.
2
Ogni pacchetto è costituito da campi
indicanti:
 tipo di servizio
 id del mittente
 id del destinatario
 timestamp
L’utilizzo dei pacchetti rappresenta non solo
una modalità con cui è possibile effettuare lo
scambio dei messaggi tra i nodi, ma permette
di venire incontro alla esigenza di invio dei
messaggi forward.
Si parla di pacchetto forward quando un
nodo, che deve inviare un messaggio ad un
destinatario che è offline, dovrà fare uso di un
terzo nodo per esplicare tale servizio. Le
entità di supporto come il server o il nodo
scelto non sono i veri destinatari del
messaggio; si realizza allora un pacchetto
forward che incapsula il messaggio di testo e
tutte le altre informazioni destinate al nodo
offline. Il destinatario del pacchetto forward
sarà invece il server. L’ID del mittente è
fondamentale per capire chi manda
fisicamente un pacchetto.
Figura1: Pacchetto forward inviato al
server
Tra i protocolli che sono stati utilizzati per
supportare gli scambi dei pacchetti si è fatto
uso dell’unicast e del broadcast.
L’unicast significa comunicazione puntoa-punto cioè, una sorgente trasmette pacchetti
ad una singola destinazione.
Il broadcast è una modalità di
comunicazione in cui ogni messaggio
trasmesso su un canale wireless è
generalmente ricevuto da tutti i destinatari
localizzati one-hop dal mittente e rispondono
agli indirizzi di una rete locale.
Un altro aspetto riguarda la scelta del
protocollo di comunicazione TCP od UDP.
Il protocollo TCP fornisce un controllo sul
flusso e sulla congestione, richiesta per
garantire un affidabile consegna dei pacchetti.
TCP fu originariamente realizzato per
lavorare in delle reti stabili. Poiché la
frequenza di errore nelle reti cablate è
abbastanza bassa, il TCP usa la perdita di
pacchetti come un indicatore di congestione
della rete. La mobilità potrebbe causare
fallimenti di routing e la perdita di pacchetti
potrebbe introdurre del ritardo.
Il TCP interpreta queste perdite come
congestione ed invoca il meccanismo di
controllo, effettuando delle ritrasmissioni.
Tale fenomeno non appare o comunque è
presente con una intensità minore se il
protocollo utilizzato è l’UDP.
Per tale motivo la scelta di optare per
quest’ultimo protocollo di comunicazione che
viene utilizzato soprattutto nei casi di mancata
connessione.
La struttura dell’architettura porta ad
identificare il ruolo di altri oggetti che
agiscono a supporto delle entità fondamentali
del sistema.
I client della rete ed il server si appoggiano
alla connection.
La connection fa da intermediario tra
client o server e router. Si occupa di
processare i pacchetti in input su richiesta del
router cioè, recupera le informazioni del
pacchetto come il tipo di servizio che viene
richiesto e, sulla base di questo, richiede la
creazione di un pacchetto specifico al livello
sottostante. Una volta creato il pacchetto di
risposta, viene inviato al router che si
occuperà di instradarlo. Un pacchetto in
output sulla connessione viene inviato sulla
rete.
Il router è l’entità che ha delle
responsabilità inerenti a ciascun host. Esso
gestione l’invio e la ricezione dei pacchetti.
Viene infatti chiamato dal dispatcher alla
ricezione di un pacchetto (gestisce l’ascolto
dell’evento ricezione pacchetto). Dal punto di
vista semantico, si trova ad un livello
superiore alla connection perché questa
estrapola le informazioni dal pacchetto e
richiede la formazione del pacchetto di
3
risposta. Il router opera le sue scelte di
instradamento del pacchetto in base al
destinatario e fa questo senza interessarsi del
tipo di servizio che era stato richiesto.
Il dispatcher è un thread in ascolto sulla
connessione. Alla ricezione di un pacchetto,
notifica il listener dell’avvenuta ricezione. Il
listener viene gestito dal router del rispettivo
host destinatario. In maniera analoga, il
dispatcher verrà chiamato dal router per le
operazioni di invio di un pacchetto.
2.Servizio
Asincrono
di
Chatting
Gli host hanno la possibilità di entrare ed
uscire dalla rete. Questo comporta
l’impossibilità di offrire i servizi ad uno o più
nodi durante il periodo di disconnessione.
A tal proposito, all’interno della MANET
si considera la possibilità di realizzare delle
comunicazioni asincrone. Per la gestione di
queste comunicazioni occorre considerare i
casi in cui nella rete è presente:


Persistent Server
Nodo incaricato
Nell’affrontare
tale
tipologia
di
comunicazione occorre affrontare e risolvere
delle problematiche che riguardano la
comunicazione sia in presenza del server che
in presenza del nodo incaricato.
Le problematiche riguardanti il primo caso
sono:




come il server conosce i partecipanti
nella rete
come gestire i pacchetti destinati ad
un nodo offline e che occorre
indirizzare al server
come i client utilizzano il server se è
già presente nella rete o se entra dopo
come evitare eventuali congestioni
dell’host destinatario



quando scegliere il nodo
come scegliere il nodo
come gestire la memoria del nodo
3.Comunicazione asincrona
con Persistent Server
Siamo nella situazione in cui non sempre
chi vuole accedere a dati o richiedere servizi è
connesso contemporaneamente a chi li offre.
In tale contesto, occorre un supporto per la
gestione delle comunicazioni asincrone e per
la memorizzazione dei messaggi in quanto, un
nodo mittente non sarebbe in grado di
recapitare un messaggio ad uno o più
destinatari fino all’ingresso di questi nella
rete.
Il server offre:
 capacita di memoria che si assumono
non limitate
 servizio di corrispondenza tra
mittente e destinatario del messaggio
 delivery del messaggio.
3.1 Ingresso nella rete del server
Il Persistent Server deve essere a
conoscenza dei nodi all’interno della rete per
poter esplicare il servizio di delivery dei
messaggi. Pertanto, all’ingresso nella rete da
parte del server, viene inviato un messaggio
di broadcast (un JOIN_NETWORK) ai
partecipanti della MANET, con il quale si dà
conoscenza agli host della presenza del
server. I nodi della rete rispondono con un
HOST_ONLINE, mediante il quale si notifica
Per il secondo caso, occorre affrontare altre
problematiche del tipo:
4
la
propria
presenza
nella
rete.
Figura 2: Broadcast del server all’ingresso
nella rete
Il server è stato implementato come una
midlet, con la quale si inzializza il server e la
sua GUI.
3.2 Rete dal punto di vista del
server
L’interfaccia del server presenta:
 partecipanti all’interno della rete
 eventuali pacchetti da inoltrare
Una volta connesso, il server apre una
propria connessione ed ha un proprio router
che mette a disposizione le funzioni di
trasmissione e ricezione dei pacchetti
verso/dalla rete.
Per una maggiore completezza dei casi
possibili, si è deciso di trattare la situazione in
cui il server arriva in un secondo momento
nella rete e non è presente quando un host
vuole inviare un pacchetto offline.
3.3 Gestione dei pacchetti
indirizzati al server e logica del
server
Come già detto nell’architettura del
sistema, le comunicazioni tra i partecipanti
della rete avvengono sulla:
 costruzione di pacchetti di messaggio
di testo o di richieste e risposte.
Da questi è possibile ottenere le informazioni
sul mittente e il destinatario del pacchetto. Al
momento di una comunicazione asincrona
però, il reale destinatario del pacchetto è
offline ed occorre indirizzare il pacchetto al
server. Si suppone dunque che al momento
dell’invio il campo relativo al mittente
contenga l’ID dell’host che manda
fisicamente il pacchetto. Grazie a questo è
possibile gestire il recapito dei pacchetti
forward che vengono costruiti dal nodo
mittente per il server.
A questo punto, sarà compito del server:
 estrapolare i pacchetti indirizzati al
vero destinatario mediante una
funzione che chiama internamente
 estrarre il destinatario di ciascun
pacchetto
 aggiungere i pacchetti nella sua
memoria in stato SEND_WAIT
Nella trasmissione e ricezione dei pacchetti
da parte del server, è stato opportuno gestire
gli stati in cui si trova un pacchetto perché,
così facendo, si può decidere cosa farne e
quali operazioni occorre applicare, essendo a
conoscenza di quelle che sono già state
effettuate.
All’arrivo di un host nella manet, il server si
occuperà di:
 verificare se esiste una corrispondenza
tra il suo id e quelli dei destinatari dei
pacchetti in memoria
 effettuare il delivery
 liberare lo spazio in memoria
cancellando i pacchetti.
Per ogni host che entra nella rete, viene
chiamata una funzione che verifica se
esistono dei pacchetti pendenti per esso. Il
server deve gestire dunque i pacchetti
pendenti per un host, pacchetti che sono
stati memorizzati sul server e sono in attesa di
essere inviati al destinatario.
Se il destinatario ha più di un pacchetto da
ricevere, per evitare una possibile congestione
della rete e del nodo destinatario, è stata
adottata una politica di gestione dell’invio dei
pacchetti che verrà spiegata nella sezione
relativa alla gestione della qualità di servizio.
5
3.3.1 Interazione asincrona
Client2Server
Il client è già connesso alla rete e desidera
inviare un pacchetto.
In base al tipo di comunicazione in
esame, il router del client verifica che il
destinatario del pacchetto non è on–line e che
è presente il server.
Se il server è già nella rete, il pacchetto
viene forwardato a quest’ultimo. I pacchetti
di forward riguardano i messaggi di testo e i
messaggi che vengono scambiati nella fase di
richiesta e risposta d’amicizia.
Il pacchetto ricevuto dal server può essere
un:
 pacchetto forward, questo
viene letto, settando il suo stato in
STATE_PROCESS_COMPLETE e si
estrapola da esso ogni singolo
pacchetto. A questo punto, ogni
singolo pacchetto viene gestito come
un pacchetto di output e il suo stato
viene posto in STATE_SEND_WAIT.
Se il destinatario del pacchetto di
messaggio non è on-line, il server si
incarica di memorizzarlo nel suo store
(PacketStore) e lo invia al momento
opportuno
con
la
successiva
eliminazione dalla memoria. Quando
il destinatario è on-line il pacchetto
viene inviato, ponendo lo stato in
STATE_SEND_COMPLETE.
 pacchetto di broadcast per
ingresso nella rete da parte di un host;
in tal caso, il server risponde
notificando la sua presenza.
3.3.2 Interazione asincrona
server2client
Si considera il caso in cui sia il server ad
effettuare il delivery dei pacchetti di
messaggi. Il server mantiene i messaggi
pendenti per un host. Quando un host entra
nella rete fa un broadcast e a questo anche il
server è tenuto a rispondere. Da questo
messaggio di input, il server va a verificare la
corrispondenza dell’id del nuovo host con
quelli dei destinatari dei messaggi che ha in
memoria. Se ci sono messaggi per il nuovo
host che è entrato nella rete, effettua l’invio.
Occorre tenere conto del fatto che i
messaggi devono essere inviati in ordine e per
questo
motivo
è
stato
introdotto
l’ordinamento secondo Lamport (vedi
relazione Davide Sansovini).
3.4 Server dal punto di vista del
client
Il client può avere una visione diversa nei
confronti del server sulla base della sua
presenza o meno nella rete.
Si distinguono i casi:


server presente da sempre nella rete
ingresso successivo del server
Il primo caso è già stato trattato in
precedenza.
Nel secondo caso, quando un host deve
inviare un pacchetto offline, lo mantiene
momentaneamente in memoria. Appena
riceve la notifica dell’ingresso del server, il
nodo che ha dei messaggi dovrà indirizzarli al
server, liberando così la sua memoria. Per
evitare delle situazioni di congestione del
server, che in questa situazione si troverebbe
ad essere stressato dai molteplici invii da
parte dei nodi, è stata adottata una politica di
controllo che verrà spiegata nella sezione
relativa alla qualità di servizio.
6
Se nella rete non è presente né il
destinatario del pacchetto, né il server, il
pacchetto viene tenuto in memoria dal client
(in stato SEND_WAIT) in attesa che il
destinatario venga on-line oppure che l’utente
decida di abbandonare la rete.(si rimanda a
dopo la spiegazione di cosa avviene e il
motivo di tale scelta).
Al momento della disconnessione del
client, i suoi pacchetti in memoria verranno
inviati al server, se è presente, o si procederà
con l’elezione di un nodo incaricato.
4. Chatting Asincrono con
Nodo Incaricato
Questa è la situazione in cui si è in assenza
del server che ha le caratteristiche migliori e
favorevoli per gestire la comunicazione
asincrona.
Fin quando un nodo è on-line ed ha dei
pacchetti di messaggi asincroni, li tiene in
memoria.
Le problematiche affrontate in questa
situazione sono:
 momento in cui eleggere il
nodo incaricato
 politica adottata per eleggere il
nodo
 gestione dei messaggi da parte
del nuovo nodo
 gestione dei possibili casi di
congestione
4.1 Momento di elezione del
nodo incaricato
E’ stato opportuno chiedersi quando è il
momento adatto ad eleggere il nodo a cui
affidare i pacchetti asincroni. Se l’elezione del
nodo venisse fatta non appena il client
verifica che il server non c’è, il nuovo nodo
incaricato potrebbe, in un secondo momento,
abbandonare la rete. A questo punto, occorre
eleggere un nuovo nodo incaricato e il nodo
che precedentemente ha inviato all’incaricato
i suoi pacchetti, entrerebbe a far parte dei
nuovi candidati a diventare nodo incaricato,
ritornando a ricevere i pacchetti di cui si era
prima liberato, più altri eventualmente. Per
evitare questo traffico e questa situazione
poco favorevole ad un host, che potrebbe
continuare a liberarsi e ricevere pacchetti, si
effettua l’elezione del nuovo nodo solo nel
momento in
cui un host decide di
abbandonare la rete.
4.2 Politica di elezione del nodo
incaricato
A questo punto, occorre decidere come
eleggere il nuovo nodo.
Si è deciso di adottare una politica di
elezione sulla base della memoria
disponibile di ogni nodo presente nella rete.
Il nodo che decide di abbandonare la rete
invia
un
messaggio
di
broadcast
(FREE_MEMORY_ASK), richiedendo la
quantità di memoria di ciascun host e aspetta
le risposte (FREE_MEMORY_RESPONSE).
Prima di abbandonare la rete, il nodo dovrà
rimanere in attesa per un tempo sufficiente ad
effettuare l’operazione di scelta ed eventuale
elezione del nuovo nodo.
Ciascun host risponde e per evitare la
congestione del nodo richiedente, si adotta
una politica di gestione degli invii.
Il nodo che ha fatto la richiesta, prende, tra
tutti gli host che hanno risposto, quello con
capacità di memoria maggiore.
4.3 Gestione dei pacchetti
A questo punto, l’host che ha richiesto la
ricerca, costruisce una lista di pacchetti da
inviare e che sono in stato SEND_WAIT. Il
pacchetto di forward viene costruito
controllando che la somma di memoria dei
pacchetti che verranno inviati, non superi la
memoria del nodo destinatario. I pacchetti
rimanenti vengono inviati al secondo
candidato in ordine di spazio e così via.
Una volta inviato il pacchetto forward, il
nodo mittente elimina dalla sua memoria i
pacchetti già inviati.
Questa soluzione viene incontro alla
politica di gestione dei pacchetti da parte di
ciascun nodo.
7
Per ogni nodo destinato a mantenere dei
pacchetti di messaggi offline (effettua lettura
del ForwardPacket e memorizza i pacchetti),
si controlla che se riesce a mantenere tutti i
pacchetti, li salva nel suo PacketStore,
altrimenti si procede con l’eliminazione dei
messaggi che hanno timestamp più vecchio.
4.4 Logica del nodo incaricato
I pacchetti ricevuti dal nodo incaricato
possono essere:
 pacchetto forward, in tal caso
occorrerà processare ogni singolo
pacchetto, estraendo il destinatario. Il
pacchetto verrà salvato nello store del
nodo. Per ogni nuovo utente che entra
nella rete, verificherà che ci siano dei
pacchetti pendenti per lui e che sono
in stato SEND_WAIT.
 pacchetto con richiesta di memoria,
in tal caso risponderà riportando la sua
memoria disponibile.
Ogni nodo che mantiene dei pacchetti di
messaggi offline, dovrà occuparsi di
distinguere:
 i suoi possibili pacchetti da inviare al
nodo offline
 pacchetti che hanno come mittente un
altro nodo che glieli ha inviati.
Per la gestione dei pacchetti pendenti da
inviare al nodo destinatario quando questo
sarà on-line, il nodo incaricato si occuperà di
inviare i pacchetti che hanno lui come
mittente, direttamente e, di richiedere la
costruzione di un pacchetto di forward per gli
altri messaggi. Alla fine dell’invio, procederà
sempre con la rimozione dei messaggi inviati.
Per effettuare l’invio dei pacchetti pendenti è
stato utilizzato un thread che viene eseguito
quando un host viene online e si hanno dei
pacchetti pendenti per lui.
Per evitare di stressare il destinatario dei
pacchetti, è stato gestito l’invio dei pacchetti
in maniera opportuna e si rimanda la
spiegazione nella sezione dedicata alla
gestione di qualità.
I nodi incaricati alla gestione dei messaggi
asincroni possono essere più di uno e al
momento della loro disconnessione, si
procede con l’elezione di un nuovo nodo
incaricato.
5. QoS management
La qualità di servizio che si vuole garantire
e che è stata oggetto di discussione in vari
punti del progetto, riguarda la possibilità di
evitare eventuali casi di congestione.
Per evitare situazioni in cui alla risposta di
un broadcast inviato da parte di un host, tutti
gli altri host della rete potessero
congestionare il richiedente con le loro
risposte, si è pensato di poter trovare una
soluzione adeguata per evitare ciò.
Figura 3: congestione
I casi di possibile congestione del nodo
destinatario riguardano:
 l’invio di più pacchetti
pendenti ad un nodo destinatario,
precedentemente offline
 l’invio di pacchetti dagli host
all’ingresso successivo del server nella
rete
 l’invio da parte degli host della
risposta alla richiesta di memoria
disponibile
Per tutti questi casi, citati già
precedentemente nelle rispettive sezioni, è
stato previsto di utilizzare un ritardo,
generato casualmente, per effettuare gli invii.
Si ha un thread dedicato che viene lanciato
nei casi citati e genera un ritardo per l’invio
dei rispettivi pacchetti.
Per il primo caso, un nodo destinatario
potrebbe avere più pacchetti da ricevere. In tal
8
caso, ogni pacchetto verrà inviato con un
certo ritardo.
Nel secondo caso, quando il server è assente,
ogni nodo mantiene i pacchetti per i
destinatari offline e all’ingresso del server
nella rete, tutti i nodi invierebbero i pacchetti
che hanno in memoria con la possibilità di
congestione. A tal proposito, dopo che il
server effettua il riconoscimento degli host
all’interno della rete, inviando il suo
messaggio di broadcast (JOIN_NETWORK),
ogni nodo verifica che il messaggio provenga
dal server. Se è così, ogni nodo procederà ad
effettuare l’operazione di creazione del
pacchetto forward e ad inviare tutti i pacchetti
pendenti al server; l’invio avverrà con un
certo ritardo generato casualmente da parte di
ciascun nodo. Il metodo dedicato verrà
chiamato solo una volta, all’ingresso del
server nella rete.
Inizialmente si era pensato di lasciare che
ogni nodo mantenesse i pacchetti pendenti
fino al momento della sua disconnessione e,
solo in quel momento, li avrebbe inviati al
server, considerando sempre l’ingresso
successivo di questo nella rete. Per non
caricare di responsabilità ogni singolo nodo,
in quanto una sua eventuale caduta avrebbe
causato la perdita dei pacchetti, è stata
realizzata la soluzione sopra citata.
Il terzo caso riguarda invece la risposta di
ogni singolo host della rete alla richiesta di
memoria disponibile. In maniera simile al
caso precedente, si rischierebbe di
congestionare il nodo che ha fatto la richiesta.
Per evitare questo, le risposte dei vari host
giungeranno in tempi diversi.
Una gestione della qualità di servizio sarebbe
stata opportuna per un’eventuale perdita di
messaggi, cosa che non è stata affrontata.
Altra situazione che non è stata trattata
riguarda l’eventuale caduta di un nodo che
comporta la perdita dei messaggi pendenti.
6. Strumenti utilizzati e test
Il progetto è stato realizzato utilizzando
come ambiente di sviluppo Eclipse e le
librerie messe a disposizione dalla J2ME.
Il progetto è stato sviluppato sfruttando
anche un tool per la coordinazione del lavoro
di gruppo: TortoiseSVN.
Su una macchina è stato creato un server
remoto usato come repository del codice
prodotto. Le fasi di test sono state necessarie
per capire il corretto funzionamento delle
varie funzionalità del sistema sviluppato.
Sono state effettuate verifiche sulle
comunicazioni a scambi di messaggi in
modalità sincrona ed asincrona, con e senza la
presenza del server.
E’ stato interessante l’utilizzo di un tool
come Ethereal con il quale si è potuto notare
il formato e tutte le informazioni presenti in
un pacchetto che viaggia nella rete.
7. Conclusioni e sviluppi
futuri
Il progetto soddisfa i requisiti fondamentali
del sistema come realizzazione del discovery,
comunicazione sincrona, asincrona ed
estensioni. Sono state considerate eventuali
situazioni come l’ingresso successivo nella
rete da parte del server.
L’obiettivo è stato quello di realizzare un
prototipo funzionante ed estendibile il più
possibile.
Gli
eventuali
sviluppi
riguardano
principalmente la replicazione dei messaggi
da inviare ad un nodo offline. Così facendo, i
messaggi non verrebbero affidati solo ad un
nodo ma a diversi, potendo prevenire perdite
di pacchetti con l’eventuale caduta di un
nodo.
Altro aspetto potrebbe essere la
replicazione del server per il bilanciamento
del carico qualora questo non riuscisse più a
sostenere il carico computazionale dovuto ad
una crescita della rete MANET.
Sarebbe importante gestire il controllo
sulla perdita dei pacchetti mediante ack
ricevuto da parte del nodo mittente. In questo
modo potremmo essere in grado di capire se
un messaggio è giunto a destinazione o meno,
con l’eventuale rinvio da parte del mittente.
A questo punto sarebbe utile gestire anche
le comunicazioni multi-hop con la necessità
di studio di adeguati algoritmi di routing.
9
Altro aspetto potrebbe essere quello di
introdurre dei meccanismi di sicurezza come
l’identificazione di un host all’ingresso nella
rete, per evitare scambi di personalità.
Bibliografia
I. Chlamtac, M. Conti, JJN Li, “Mobile ad
hoc
networking:
imperatives
and
challenger”, Elsevier Journal of Ad Hoc
Networks, vol.1, no.1, 2003.
K. Topley, “J2ME in a nutshell”, O’Reilly,
2002.
A. Corradi, Slide del Corso di Reti di
Calcolatori L-S e L-A.
TortoiseSVN: http://tortoisesvn.tigris.org/
C. Tschudin, E. Osipov “Estimating the Ad
Hoc Horizon for TCP over IEEE 802.11
Networks”
10