Interazione VoRaQue Nomade

Passiamo ora ad esaminare come ogni istanza di VoRaQue comunica con i nodi vicini (figura 5.7).

Come si nota in figura, l’interazione tra l’applicazione di alto livello e Nomade avviene inserendo/prelevando oggetti, che chiameremo messaggi, in/da due code sin-

Architettura e Implementazione

Figura 5.7: Interazione VoRaQue - Nomade - Rete

cronizzate. Inoltre, viene impiegato un socket UDP per inviare (ricevere) messaggi a (da) nodi remoti. E’ importante sottolineare che Nomade mette a disposizione per l’applicazione di alto livello le API per invocare funzionalità utili per gestire l’overlay network, quali l’inserimento, la cancellazione e la gestione del keep alive [50]. Come specificato sopra, queste operazioni possono essere invocate da VoRaQue inviando nel- la coda di output i messaggi definiti nel protocollo di Nomade. Le classi implementate nel package lowerlevel si occupano dell’integrazione tra le due applicazioni e si pre- occupano anche di convertire i dati che vengono scambiati tra VoRaQue e Nomade. Osserviamo la figura 5.8.

L’interfaccia LowerLevel mette a disposizione del Server una lista di metodi. La loro implementazione si trova nella classe LowerLevelWrapper, che ha il compito di convertire la richiesta proveniente dall’applicazione di alto livello in una richiesta che possa essere soddisfatta da Nomade. Ad esempio, supponiamo che VoRaQue invochi il metodo per la join. In questo caso, il LowerLevelWrapper si preoccupa di creare e mandare in esecuzione il thread VonNodeThread che a sua volta istanzia un oggetto di tipo Nomade e inserisce nella sua coda di output la richiesta di inserimento nella rete di overlay sotto forma di un messaggio di JoinRequestV1, che è definito nel protocollo di Nomade. Il thread aspetta quindi la conferma5 _{dalla coda in input. Al termine, il}

LowerLevelWrapper esegue la conversione del risultato restituito da Nomade nel tipo di risultato atteso da VoRaQue.

In figura 5.8 viene definito anche un package messagetonomade. Come abbiamo

5_{In realtà, come definito nelle API di Nomade, la conferma si desume dalla ricezione di messaggi di}

tipo NewAvatarV1.

5.4 Nomade e lowerlevel Package

Architettura e Implementazione

visto all’inizio del capitolo, in esso sono implementati tutti i messaggi che vengono spediti all’applicazione di basso livello con i corrispondenti gestori. Per fare questo, si è scelto di incapsulare gli oggetti di tipo Message dell’applicazione di alto livello in messaggi che potessero essere manipolati da Nomade per essere inoltrati sull’overlay network. Osserviamo il diagramma delle classi di figura 5.9.

Come possiamo vedere, nel package messagetonomade di VoRaQue sono definiti due messaggi, ApplicationMessage e ApplicationMessageRequest, che hanno come variabile privata un oggetto Message, e due gestori, ApplicationMessageHandler e ApplicationMessageRequestHandler. Ognuno di essi implementa la corrispondente interfaccia definita in Nomade. Da notare che, quest’ultimo utilizza un dispatcher per elaborare i messaggi scegliendo il gestore appropriato, affinché ciò sia possibile, è necessario eseguire un’operazione di registrazione messaggio-gestore.

Ma vediamo come queste classi vengono utilizzate. Nell’istante in cui il Server invoca il metodo sendMessageToLowerLevel (figura 5.9) per spedire un pacchetto in rete, il LowerLevelWrapper crea un’istanza di ApplicationMessageRequest e inizia- lizza la sua variabile privata message (figura 5.9) con il messaggio del Server. Fatto questo, viene invocato VonNodeThread che inserisce nella coda di output il messaggio ApplicationMessageRequest. Il dispatcher invoca il gestore corrispondente (Appli- cationMessageRequestHandler) che costruisce il pacchetto ApplicationMessage e lo invia tramite il socket UDP.

L’istanza di Nomade che riceve dalla rete questo messaggio, via dispatcher invoca ApplicationMessageHandler, il quale, mantenendo il riferimento all’oggetto di tipo LowerLevel, estrae l’oggetto Message dal pacchetto ricevuto e viene passato come parametro al metodo sendMessageToServer (figura 5.9) per inserirlo nella coda del Server.

Abbiamo visto come l’interazione VoRaQue - Nomade permetta la spedizione e la ricezione dei messaggi definiti nel capitolo 4. L’applicazione di basso livello mantiene le strutture dati per la gestione del diagramma di Voronoi del nodo corrente. Queste 118

5.4 Nomade e lowerlevel Package

Architettura e Implementazione

informazioni sono utili per l’elaborazione dei messaggi da parte del Server, in par- ticolar modo quando devono essere elaborate richieste di query esatte o range query che richiedono la conoscenza dei Voronoi Neighbours e/o Close Neighbours (vedere capitolo 4). Tali strutture dati non possono essere accedute direttamente, ma anche in questo caso viene inviata una richiesta a Nomade tramite la coda in output e si attende la risposta sulla coda in input. Osserviamo la figura 5.10.

Nel package messagetonomade sono definiti i messaggi VoronoiNeighborMes- sage e VoronoiNeighborReply e il gestore associato al primo. Ognuno di essi imple- menta la corrispondente interfaccia definita in Nomade.

La classe VoronoiNeighborMessage mantiene una variabile booleana che sta ad indicare se sono richiesti soltanto i vicini confinanti oppure sia i Voronoi Neighbours che i Close.

Nell’istante in cui il Server invoca il metodo getFrontiereGreedy dell’interfac- cia LowerLevel, il LowerLevelWrapper crea un’istanza di VoronoiNeighborMessage e viene invocato VonNodeThread che inserisce nella coda di output il messaggio. Il dispatcher invoca il gestore corrispondente (VoronoiNeighborMessageHandler), il quale crea la reply VoronoiNeighborReply che restituisce una copia della lista dei vici- ni. Da notare che in questo caso viene definito un gestore in meno perché è VonNode- Thread che si preoccupa di estrarre dal messaggio la struttura dati e restituirla al Server. Inoltre, quest’ultimo esegue un’attesa attiva, ovvero, per poter portare avanti l’elabo- razione deve aspettare la risposta da Nomade. Nel caso precedente, nel quale viene inviato un messaggio in rete, non appena il Server ha invocato il metodo sendMes- sageToLowerLevel (figura 5.9), può iniziare a elaborare la nuova richiesta se questa è in coda, altrimenti passa nello stato di attesa, in particolare attesa passiva.

5.4 Nomade e lowerlevel Package

Architettura e Implementazione