DEIS Università di Bologna 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 DISCOVERY_REQUEST client DISCOVERY_RESPONSE BROADCAST UNICAST manager1 manager2 protocollo usato dal nodo per conoscere i gruppi gestiti dai nodi del vicinato 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) manager JOIN_REQUEST ACK BROADCAST UNICAST #1 membro#2 #N del gruppo #n protocollo usato dal nodo per associarsi(disassociarsi) ad un gruppo presente nel vicinato il nodo invia una richiesta JOIN_REQUEST(LEAVE_REQU EST) in unicast verso il gestore del gruppo e si mette in attesa della risposta ACK(LEAVE_RESPONSE) il gestore che riceve una richiesta di join(leave) risponde al mittente e notifica tutti i membri del gruppo (pub/sub) con un messaggio di ACK(LEAVE_RESPONSE) in unicast 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 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 il nodo gestore invia una richiesta HANDOVER_REQUEST in broadcast limitato e si mette in attesa di offerte HANDOVER_REQUEST manager HANDOVER_RESPONSE HANDOVER_ACCEPT BROADCAST UNICAST 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 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 associato al gruppo.

Limiti del middleware e conclusioni C’è un punto di 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 “best- effort”, 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à di servizio