Reti di Calcolatori LS
Emiliano Capoccia
DEIS Università di Bologna
Reti MANET
- Reti non strutturate, create e
configurate in maniera dinamica
- Nodi eterogenei per capacità di calcolo
e banda
- Alta mobilità (roaming) dei nodi,
instabilità delle configurazioni della rete
-
Obiettivi
Scenario computazionale nuovo: necessità di
instaurare comunicazione con i nodi vicini senza
conoscenza pregressa, in un dato momento ed in una
data località
Applicazioni collaborative di nuova concezione
necessitano di nuovi servizi:
-
esplorazione dinamica della rete circostante
possibilità di comunicare con i nodi vicini
possibilità di gestire gruppi, eventualmente
partizionati, per supportare funzionalità applicative
avanzate
Il middleware sviluppato realizza le funzionalità
elencate consentendo all’utente di occuparsi solo
della implementazione della parte specifica
dell’applicazione
Comunicazione
di
base
- il middleware è basato sulla JVM e le socket (UDP);
ogni nodo deve avere la sua JVM con il middleware
installato per poter mettere in esecuzione le
applicazioni. L’ipotesi di base IP statico nei nodi (rete
non strutturata)
-
comunicazione punto-punto mediante send/receive
ordinarie
comunicazione punto-multipunto mediante broadcast
in una rete MANET il broadcast raggiunge tutti i nodi
direttemente connessi al nodo che effettua il broadcast
nel middleware il broadcast è propagato in flooding alle
reti vicine, per un raggio limitato e programmabile; il
raggio di località si può impostare dinamicamente a
runtime, mediante apposito protocollo, e supporta
politiche avanzate globali di gestione.
Architettura
-
Struttura stacked, dove
GML si appoggia a BSL
BSL estende i servizi di
comunicazione di base
della JVM
GML usa la
comunicazione avanzata
offerta da BSL per
introdurre la gestione dei
gruppi, il roaming e la
rilocazione della gestione
-
Middleware layered:
BSL
estensione delle modalità di
comunicazione di base
implementazione del concetto di
località
realizza le funzionalità di esplorazione della rete circostante e di
comunicazione con i vicini menzionate negli obiettivi
estende il broadcast di base fornito dalla JVM con un meccanismo di
flooding limitato
stateful: soft state comprende informazioni sul vicinato (nodi
raggiungibili e loro indirizzo di rete) e durante le comunicazioni
mantiene informazioni su messaggi frammentati
adattatività: BSL fa affidamento alla ricezione in broadcast dei beacon
dei nodi vicini per aggiornare adattativamente lo stato alle variazioni
della topologia
Esempio di topologia di
rete
Nodi in visibilità diretta
Località; raggio 2
punto di vista di (2)
Località; raggio 2
punto di vista di (5)
Middleware layered:
GML
gruppo: insieme di entità interagenti associate, ognuna dotata di
un profilo che ne descrive caratteristiche, interessi e capacità
-
-
gruppi partizionati, presenti in insiemi di nodi disgiunti nella rete
complessiva
GML realizza l’obiettivo di gestione di gruppi:
-
-
creazione di un gruppo (sul nodo gestore)
discovery dei gruppi nel vicinato
possibilità di associarsi/disassociarsi da un gruppo esistente
nel vicinato
supporto alla mobilità dei nodi (roaming): viene mantenuto lo
stato di associazione ad un gruppo in mobilità
un protocollo specifico permette di rilocare la risorsa gruppo (e
la sua gestione) ad un diverso nodo nel vicinato (handover)
GML (molto) stateful: punto di centralizzazione sul gestore e info
di stato estese (composizione dei gruppi, profili,...)
Protocollo DISCOVERY
BROADCAST
-
UNICAST
manager2
protocollo usato dal nodo per
conoscere i gruppi gestiti dai nodi
del vicinato
client
DISCOVERY_REQUEST
DISCOVERY_RESPONSE
-
-
-
manager1
DISCOVERY_RESPONSE
il nodo invia una richiesta
(DISCOVERY_REQUEST) in
broadcast limitato e si mette in
attesa di risposte per un certo
periodo
la richiesta può riferirsi a gruppi di dato profilo o essere
generica (tutti i gruppi)
i nodi gestori che ricevono la DISCOVERY_REQUEST i
cui gruppi fanno match col profilo richiesto, inviano un
messaggio di DISCOVERY_RESPONSE in unicast al
richiedente notificandogli la presenza del gruppo
Protocollo JOIN(LEAVE)
-
BROADCAST
protocollo usato dal nodo per
associarsi(disassociarsi) ad un
gruppo presente nel vicinato
UNICAST
manager
membro#2
#1
-
del gruppo #n
JOIN_REQUEST
ACK
il nodo invia una richiesta
ACK
JOIN_REQUEST(LEAVE_REQU
EST) in unicast verso il gestore
del gruppo e si mette in attesa
della risposta
il gestore che riceve una richiesta di join(leave)
ACK(LEAVE_RESPONSE)
risponde al mittente e notifica tutti i membri del gruppo
(pub/sub) con un messaggio di
ACK(LEAVE_RESPONSE) in unicast
ACK
-
#N
comunicazione stateful (messaggi numerati):
esecuzione di una routine di callback all’arrivo della
risposta ACK(LEAVE_RESPONSE); la richiesta di
join(leave) è asincrona non bloccante
Protocollo HANDOVER
-
-
BROADCAST
UNICAST
protocollo usato da un nodo gestore per
realizzare la rilocazione della gestione
verso un altro nodo del vicinato
(tipicamente per batteria prossima a
terminare). Protocollo di bidding
manager
HANDOVER_REQUEST
HANDOVER_RESPONSE
HANDOVER_RESPONSE
il nodo gestore invia una richiesta
HANDOVER_REQUEST in broadcast
limitato e si mette in attesa di offerte
tutti i nodi che ricevono una HANDOVER_REQUEST e possono
potenzialmente gestire gruppi, inviano in unicast al richiedente la
propria HANDOVER_RESPONSE contente informazioni sulla
capacità di prendere in carico la gestione
HANDOVER_ACCEPT
-
il nodo gestore attende le risposte alla propria
HANDOVER_REQUEST per un certo intervallo di tempo, allo
scadere del quale calcola quale fra i nodi offerenti è il migliore e
deve passare a fare da gestore; a quel punto invia in broadcast
limitato un messaggio di HANDOVER_ACCEPT contenente
l’identità del nuovo gestore e smette di gestire. Rimane tuttavia
Limiti del middleware e
• C’è un punto diconclusioni
centralizzazione nel nodo gestore di
ogni gruppo; se tale nodo cade prima di aver
effettuato l’handover, parte dei servizi risultano
compromessi
•
•
•
Anche in presenza di perdita di messaggi di protocollo
alcuni nodi possono vedere compromessa la
funzionalità di gruppo; il middleware gestisce “besteffort”, senza qualità
Il pregio maggiore sta nella scalabilità del middleware
e nella adattività dello stesso alle variazioni di
topologia della rete
In conclusione, il middleware stesso può costituire un
valido supporto per applicazioni collaborative che non
richiedano qualità di servizio; viceversa, occorre
estendere il middleware stesso ed aggiungere in cima
ai layer esistenti uno strato che implementi la qualità