Global Virtual Tuple Space GVTS Global Virtual Tuple Space Presentazione di: Davide Tartaglione

Outline Obiettivo MANET e Spazio di tuple GVTS: modello, architettura, realizzazione Componenti esterni: Agape e LighTS Applicazione di testing e prototipo(Susi) Estensioni future

Obiettivo Realizzazione di una GVDS (Global Virtual Data Structure) che fornisca una astrazione di spazio di tuple condiviso tra tutti i membri di uno stesso gruppo in ambiente MANET.

Mobile Ad-hoc NETwork Dispositivi mobili → Carico computazionale leggero Connessioni intermittenti → Comunicazioni asincrone Contesto dinamico → Consapevolezza (Awareness)

Spazio di tuple Tuple space tuple Insieme strutturato di relazioni, intese come contenitori di attributi e valori, che realizza in pratica una astrazione di memoria condivisa Si possono depositare/estrarre informazioni di alto livello senza possibilità di causare interferenze Modello classico Linda (Gelernter) Comunicazione disaccoppiata e poco sincrona sia in tempo che in conoscenza reciproca

GVTS Alternative per l’allocazione dello spazio di tuple: Tutta su un unico membro Partizione su tutti i membri che compongono il gruppo Su un numero ristretto di membri (SuperPeer) S1 S2 P1 P5 P4 P3 P2 in(t1) out(t2,s2) rd(t2)

Primitive realizzate Modalità annotata e non annotata out rd t1 in Tuple space Modalità annotata e non annotata Semantica non bloccante Si è privilegiata la non perdita di tuple

Scelta del middleware: AGAPE AGAPE oltre a risolvere problemi di comunicazione (routing, gestione dei gruppi, etc.) Fornisce il concetto di vista come Collezione di dati relativi ai membri di un gruppo Recapitata ad intervalli regolari a tutti i partecipanti al gruppo dagli LME (Locality Manager Entity, entità che supportano le operazioni di group management) Ogni membro può così conoscere in ogni momento quanti e quali sono i SuperPeer raggiungibili Essendo gli LME nodi con maggiori capacità computazionali, questi risultano particolarmente adatti a ricoprire il ruolo di SuperPeer

Spazio di tuple locale: LighTS Sviluppato in Java dal politecnico di Milano Semplice: poche primitive Leggero: jar di 11 KB Estendibile

SuperPeerTupleManager Architettura AGAPE ServerManagers ClientManagers PeerTupleManager SuperPeerTupleManager APPLICATION GVTS LighTS I ClientManagers e i ServersManagers comprendono tutti i gestori, uno per ogni primitiva annotata, che realizzano i protocolli per le varie operazioni rispettivamente lato client e server Il PeerTupleManager realizza le primitive non annotate Il SuperPeerTupleManager filtra e soddisfa direttamente le richieste riguardanti la porzione di spazio di tuple da lui gestita

Out annotata Out(t1, Sp1) T1 LighTS OutCManager OutSManager timeslice t dest ID OutCManager OutSManager Richieste pendenti Richieste recenti LighTS OutReqMessage (1p1, Sp1, T1) T1 1p1 Sp1 t1 100 3 1p1 Sp1 100 OutResMessage (1p1, T1)

Considerazioni Il protocollo così strutturato garantisce la non perdita di tuple tuttavia: In caso di ritrasmissione di un’OutReqMessage conseguentemente alla perdita del corrispettivo OutResMessage, relativo ad una richiesta la cui entry è già stata rimossa dalla tabella delle richieste recenti, possiamo avere la duplicazione di una tupla nello spazio Se l’operazione fallisce all’ultimo tentativo causa perdita dell’OutResMessage, l’OutCManager può erroneamente considerare come non effettuata una out che invece è stata eseguita

Primitive non annotate Realizzate dal PeerTupleManager sfruttando quelle annotate fornite dal livello sottostante Reiterazione della corrispondente primitiva annotata con SuperPeer scelto a caso (sempre diverso), fino al successo della stessa o esaurimento dei SuperPeer disponibili N.B. Per come è stata realizzata la out annotata, la corrispondente primitiva non annotata potrebbe portare, oltre che alla duplicazione della tupla in uno spazio, anche all’inserimento di questa nello spazio di più SuperPeer OutReqMessage S1 PeerTupleManager OutReqMessage Out(t1) S2 OutResMessage

Testing del GVTS

Prototipo: Susi (Supporto al servizio di sicurezza di un locale)

Susi Ruoli: capo (Superpeer), bodyguard (Peer) Funzionalità: Assegnamento compito Cambiamento del compito Emergenza Scambio di messaggi Comunicazione e coordinamento basati esclusivamente su primitive del GVTS Testing effettuato nel Lab2 coinvolgendo fino a sette macchine: 2 capi e 5 bodyguards

Estensioni future Ampliamento del set di primitive messe a disposizione dal GVTS (rdAll,inAll…etc) Introduzione di nuove funzionalità che permettano ad esempio ad un SuperPeer di cedere le proprie tuple in fase di leave dal gruppo Adozione di politiche di replicazione di tuple che ne consentano la non perdita a fronte di guasti Adozione di politiche di load balancing che consentano di bilanciare l’occupazione di memoria da parte dei dispositivi SuperPeer

FINE