GVTS
Global Virtual Tuple Space
Davide Tartaglione
Presentazione di:
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
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
Tuple space
tuple
GVTS
Tutta su un unico membro Partizione su tutti i membri che compongono il
gruppo Su un numero ristretto di membri (SuperPeer)
Alternative per l’allocazione dello spazio di tuple:
S1 S2
P1
P5
P4
P3
P2
in(t1)
out(t2,s2)
rd(t2)
Primitive realizzate
Modalità annotata e non annotata Semantica non bloccante Si è privilegiata la non perdita di tuple
Tuple space
t1in
out
t1
rd
t2
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
Architettura
AGAPE
ServerManagersClientManagers
PeerTupleManager
SuperPeerTupleManager
APPLICATION
GVTSLighTS
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
1p1 Sp1 t1 100 3
Out(t1, Sp1)
OutReqMessage (1p1, Sp1, T1)1p1 Sp1 100
ntimeslice
tdestIDtimeslice
destID
OutCManagerOutSManager
Richieste pendenti Richieste recenti
LighTS
T1
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
PeerTupleManager
S1
S2
Out(t1)
OutReqMessage
OutReqMessage
OutResMessage
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
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