DHT layer

Nel primo prototipo di architettura non `e presente il livello IML, in quanto le ca- ratteristiche che dovrebbe implementare vengono gi`a fornite dai livelli di Query & Provide Interface. Per quanto riguarda la scelta del namespace infatti tali moduli effettuano gi`a l’aggancio passandone il nome alla classe DhtObjectFactory. Risulta invece essenziale la presenza di un livello che permetta di uniformare i comportamenti delle varie DHT, rispetto alle operazioni di put get e remove, verso i livelli pi`u alti dell’archittetura, fornendo un meccanismo che renda invisibili le varie differenti implementazioni tra tipi diversi di DHT.

Questo livello `e costituito principalmente dalle classi che estendono la classe astratta AbstractDhtObject. Una volta che il namespace `e stato creato esso `e as- sociato per tutta la sua durata ad un DHT particolare. In generale l’associazione viene fatta dalla classe DhtObjectFactory al momento della creazione del name- space. Tale operazione sceglie tra le DHT esistenti o tra quelle possibili una che soddisfi i criteri che il namespace impone attraverso delle feature list. Una vol- ta completato l’iter di creazione viene ritornato un oggetto che estende la classe

astratta AbstracDhtObject ma che al contempo `e il riferimento a quel tipo di DHT particolare.

Nel caso di AEM si ritorna un oggetto di tipo DhtObjectBamboo. Questa classe ha il compito di fornire un interfaccia comune per i metodi di put get e remove verso Bamboo. Infatti Bamboo utilizza una semantica particolare per tali operazioni che si differenzia da quelle utilizzate da altre implementazioni tipo Overlay Weaver ad esempio.

Un esempio tipico `e quello della remove. Nel caso di Bamboo infatti per effet- tuare la remove `e necessario fornire sia la chiave che il valore ad essa associato. Quando si utilizza tale operazione tuttavia non siamo a conoscenza dei valori a cui la chiave `e associata, di conseguenza la remove che la classe DhtObjectBamboo implementa in particolare effettua prima una get con la chiave da togliere, ed una volta reperito il valore effettua la remove. Nel caso di Overlay Weaver invece tale operazione non `e necessaria.

Quindi la gerarchia delle classi che ha come vertice la classe AbstractDhtObject fornisce un insieme di metodi che le classi che la estendono devono fornire tuttavia l’implementazione effettiva `e diversificata a seconda della DHT con la quale si interagisce.

4.2.5

Implementazioni di DHT utilizzate

4.2.5.1 Overlay Weaver

Descrizione. Overlay Weaver (OW)[9] `e l’implementazione di una DHT basata su Java che riesce a sfruttare diversi tipi di algoritmi di routing che appartengono ai pi`u comuni tipi di DHT quali Chord, Pastry, Tapestry, Kademlia e Koorde. Per questo OW viene anche definito “un toolkit per la creazione di overlay”.

L’idea centrale di Overlay Weaver `e stata quella di estrapolare dal livello di routing un livello comune a tutti questi algoritmi, in modo da poter permettere all’utiliz- zatore finale di poter combinare anche le caratteristiche di tali algoritmi.

OW non `e stato usato nel primo prototipo di ADS, tuttavia sono state predisposte le classi che si agganciano a tale DHT (DhtObjectOW), si prevede infatti che

4.2. PRIMO PROTOTIPO DI ADS: IMPLEMENTAZIONE. 53

nel successivo sviluppo del codice si possano sfruttare le caratteristiche di un architettura cos`ı versatile.

Operazioni. L’inserimento di un dato sulla DHT `e effettuato tramite l’operazio- ne di put. Sono presenti due metodi che svolgono questa funzionalit`a: put(ID key, V value, long ttl)`e il primo metodo e inserisce la coppia chiave-valore nella DHT. Esiste tuttavia la possibilit`a di associare pi`u valori alla stessa chiave, ma valori uguali sono unificati.

Il parametro ttl,espresso in millisecondi, rappresenta il periodo temporale in cui il dato `e valido ed `e a disposizione sulla rete. Passato il valore indicato dal ttl il dato viene rimosso.

Il parametro hashedSecret `e un oggetto che viene associato alla coppia chiave- valore per aspetti di sicurezza. In realt`a, la rimozione di una chiave `e permessa solo se all’operazione `e associato l’oggetto segreto corrispondente.

Per recuperare dati sulla DHT `e utilizzato il metodo get(ID key) il quale restituisce l’insieme di valori associati alla chiave (key) specificata. Se nessun valore `e stato trovato null `e restituito. Esistono due possibili metodi per la rimozione di un dato dalla DHT. Il metodo remove(ID key, V value, ByteArray hashedSecret) rimuove la coppia chiave-valore specificata. Se alla chiave `e associato pi`u di un valore, `e rimosso solo quello indicato dal metodo. Il metodo remove(ID key, ByteArray hashedSecret)rimuove tutti i valori associati alla chiave specificata (oltre che la chiave stessa).

4.2.5.2 Bamboo

Descrizione Bamboo[10] `e l’implementazione in parte in codice Java a e in par- te in codice C di una DHT basata su pastry. In realt`a il protocollo pastry `e stato reingegnerizzato da parte dei creatori. L’implementazione di Bamboo `e forte- mente basata sul modello SEDA[11]. Questo modello organizza il programma in blocchi logici che possono comunicare fra di loro tramite dei messaggi ai quali altri blocchi possono registrarsi per averne notifica. Ognuno di questi blocchi `e chiamato stage. Per compiere il lavoro necessario alla DHT sono necessari almeno i seguenti stages:

4.2. PRIMO PROTOTIPO DI ADS: IMPLEMENTAZIONE. 55 • network: gestisce i messaggi di rete tcp;

• router: rende raggiungibili tutti i nodi che partecipano alla rete ; • datamanager: registra le chiavi all’interno del nodo;

• storagemanager: permette la duplicazione delle chiavi nel leafset;

• DHT: astrae la DHT permettendo le put e get, ma richiede parametri passati dal gateway;

• gateway: permette di utilizzare le put e get tramite chiamata RPC;

nel nostro caso `e stato utilizzato un ulteriore stage chiamato webserver che serve ad attivare uno strumento di controllo dei nodi, esso visualizza il carico, il leafset e il neighrborood set del nodo tramite interfaccia web.

Operazioni Implementa put, get e remove di una chiave. La put oltre alla chia- ve e al valore prende anche un parametro che si chiama secret-hash, nel caso si effettui una put su una chiave gi`a esistente se il secret-hash `e uguale a quello gi`a presente nella DHT viene effettuato un accodamento del nuovo valore a quello precedente se il valore `e diverso altrimenti viene riscritto quello precedente, al- trimenti se la secret-hashput `e diversa allora si provvede a creare un’altra entry nella DHT con chiave uguale ma con secred-hash differente. Una volta che verr`a effettuata una get sulla chiave essa restituir`a tutti i valori associati ad essa anche se avranno secret-hash differente.

La remove viene implementata passando come valori la chiave, il valore e il secret- hash associati alla chiave da cancellare.

L’Expiration Time (TTL) `e associato alla put, ogni volta che si effettua la put con chiave e secret-hash uguale a quello gi`a esistente il TTL viene rinnovato al valore max(time1+ T T L1, time2+ T T L2). Tuttavia chiavi uguali ma con secret-hash

differenti possono avere TTL differenti. Nel caso della remove anch’essa prende in input un TTL che per ragioni di correttezza dovrebbe essere maggiore di quello inserito nella input. In genere si preferisce inserire un TTL uguale a quello della put.

4.2.5.3 Chord# (Zib)

Chord#, sviluppata dallo Zuse Institute Berlin, `e un implementazione di una DHT principalmente usata con fini di publish/subscribe. Parte di essa `e stata sviluppata utilizzando Erlang.

Nel caso di ADS essa `e stata prevista considerando le sue funzionalit`a di DHT transazionale. Essa infatti dovrebbe avere il compito di mantenere tutte le meta informazioni che riguardino i namespace attivi sulla griglia al fine di coordinarne al creazione e la gestione.

Sostanzialmente un nodo nel momento in cui richiede informazioni riguardanti un namespace `e possibile che debba rivolgersi a questa DHT, tale meccanismo presenta al suo interno operazioni consistenti in sezioni critiche che richiedono l’utilizzo in mutua esclusione della DHT, per garantire la consistenza dei dati ed evitare collisioni.

4.2.6

Interazione con RSS

RSS come gi`a descritto in precedenza si occupa di effettuare un primo filtraggio dei nodi presenti sulla griglia rispetto ai criteri che sono elencati nel JSDL . Tali criteri corrispondono ad un certo tipo di risorse statiche che l’utente intente cer- care. L’RSS ritorna quindi un risultato nella forma GLUE e la richiesta JSDL inoltrata da ADS.

Sostanzialmente la dinamica dell’interazione tra ADS e RSS avviene attraverso le interfacce MAPI che gestiscono le richieste dell’AEM. La richiesta viene inizial- mente inserita in una coda e successivamente viene estratta dalla coda da un th- read. Il thread successivamente una volta estrapolata la richiesta sottoforma di og- getto AEMRequest crea un nuovo oggetto RssReplyObject che servir`a all’RSS per poter effettuare la callback una volta generata la risposta. L’oggetto RssReplyOb- jectche contiene incapsulata la richiesta viene passato al metodo della classe che RSS espone per effettuare le richieste ossia QueryForward.forwardJSDLQuery. Una volta generata la risposta in GLUE RSS utilizza il metodo setGlueResponse della classe RssReplyObject per rimandare la risposta indietro. Tale metodo che

4.3. INTERAZIONE CON I CLIENTI DI SRDS 57