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