Comunicazione

Nel package communication `e contenuta la porzione dedita a rendere possibile la comunicazione tra piattaforme di esecuzione e relativi Client.

La comunicazione `e stata modellata tramite l’interfaccia Communication, utilizza- ta da tutti i dispositivi che necessitano di comunicare con un Client. Communication si astrae dall’implementazione che verr`a effettivamente utilizzata per comunicare ed esprime le funzionalit`a che ogni metodologia di comunicazione deve fornire.

Il campo device indica il dispositivo relativo ad una particolare istanza di

Communication. Ogni dispositivo che necessita di comunicare ha il proprio oggetto addetto alla comunicazione.

La funzione startServer `e stata inserita per restare in ascolto di potenziali messaggi in ingresso. Utilizzata principalmente dal Supporto, per attendere messaggi da parte di eventuali Client. Il parametro indica quale azione bisogna intraprendere a fronte di un messaggio in arrivo. Nel caso in cui ad usare questa funzionalit`a sia il Supporto, `e stata predisposta la serverCallback, cio`e le azioni previste di default che il Supporto deve eseguire a fronte di un messaggio. Questo riduce e semplifica il codice necessario ad inizializzare una rete che resti in ascolto di messaggi da parte di Client esterni, evitando

4.1 Sotto-sistema Server 4. Implementazione

Figura 4.6: Package communication

di specificare la callback per il Supporto, in quanto `e molto complesso che le azioni da attuare varino rispetto a quelle di default. stopServer `e la funzione complementare alla precedente, che chiude il canale di comunicazione.

La funzione extractMessage serve ad estrarre il messaggio ricevuto dal canale di comunicazione effettivamente utilizzato. La funzione send invia un messaggio al Client associato al dispositivo indicato dal campo device.

Comunicazione tramite Socket `

E stata prevista un’implementazione che fa uso di Socket per permettere la comunica- zione. In questo caso il canale di comunicazione `e un AsynchronousSocketChannel. La definizione di serverCallback indica che, se il messaggio rappresenta la volont`a di entra- re in rete da parte di un client, viene estratto l’indirizzo di partenza della comunicazione (l’indirizzo del client) e viene reindirizzata la richiesta al Supporto, che la gestir`a come detto in precedenza. In tutti gli altri casi, il messaggio viene reindirizzato direttamente al Supporto e gestito come specificato in 4.1.3.

Messaggi

Gli oggetti scambiati nelle comunicazioni tra le varie entit`a sono stati modellati trami- te la classe Message. Un messaggio contiene al suo interno l’id del mittente, la tipologia

4. Implementazione 4.1 Sotto-sistema Server

di messaggio ed il contenuto del medesimo.

Per evitare ogni tipo di problematica dovuta alle potenziali diverse rappresentazioni delle tipologie di messaggi nei vari membri della rete, quelle disponibili sono state definite a priori tramite un enumeratore. In base alla tipologia di messaggio varia anche il significato del contenuto.

• Execute: messaggio che rappresenta un ordine di esecuzione.

Viene inviato dal Supporto quando le piattaforme devono iniziare ad eseguire il programma aggregato. A loro volta, le piattaforme di esecuzione remota inoltrano il messaggio al Client per far s`ı che questi ultimi possano iniziare ad eseguire. Il contenuto `e nullo in quanto tutte le informazioni relative all’esecuzione sono gi`a presenti all’interno delle varie piattaforme di esecuzione.

• Result: messaggio contenente il risultato di una computazione Scafi.

Utilizzato da tutti i dispositivi per condividere il loro risultato con i vicini, aggior- nando di conseguenza il loro stato.

• Status: messaggio contenente un aggiornamento di stato, utilizzato dal gestore delle comunicazioni Protelis.

Il contenuto `e lo stato aggiornato da condividere.

• Show: messaggio contenente un oggetto da far visualizzare al destinatario.

Utilizzato principalmente dalle piattaforme di esecuzione locale per indicare ai corrispettivi Client di visualizzare i risultati ottenuti. Questa tipologia `e stata separata dalle precedenti in quanto `e possibile che il risultato da visualizzare non sia esattamente quello utilizzato per aggiornare lo stato delle piattaforme. Cos`ı facendo si mantiene una maggiore flessibilit`a, anche in vista di potenziali nuovi adattatori che potranno essere aggiunti in futuro.

• Join: messaggio inviato da un Client per entrare a far parte della rete di dispositivi. Il contenuto del messaggio `e il numero di porta dove inviare le comunicazioni dirette al Client. L’indirizzo IP viene estrapolato dalla connessione stessa, quindi non `e necessario inserirlo nel contenuto del messaggio.

• ID: messaggio di risposta al precedente messaggio, inviato dal Supporto al Client. Indica a quest’ultimo l’identificativo assegnato alla sua piattaforma di esecuzione all’interno della rete.

• SendToNeighbours: messaggio da inviare ai vicini del mittente.

Il destinatario `e sempre il Supporto, che inoltrer`a il contenuto, che `e un altro messaggio, ai destinatari finali.

4.1 Sotto-sistema Server 4. Implementazione

• GoLightWeight: messaggio utilizzato da un Client per entrare in modalit`a di esecuzione locale.

Il contenuto `e nullo in quanto il Server conosce gi`a tutto il necessario per trasfor- mare la piattaforma di esecuzione da remota a locale (4.1.3).

• LeaveLightWeight: messaggio utilizzato da un Client per uscire dalla modalit`a di esecuzione locale.

Il contenuto `e ancora una volta nullo, in quanto il Client conosce gi`a tutto il necessario per ricominciare ad eseguire.

Tipologia di messaggio Contenuto

Execute -

Result il risultato effettivo

Show l’oggetto da visualizzare

Status lo stato aggiornato

Join la porta da utilizzare

ID l’id assegnato

SendToNeighbours il messaggio da inoltrare

GoLightWeight -

LeaveLightWeight -

4. Implementazione 4.1 Sotto-sistema Server

Serializzazione

Dovendo comunicare anche attraverso oggetti complessi tramite Socket, `e fondamen- tale che tali oggetti siano serializzabili per poter essere inviati e ricevuti in modo corret- to. Nella maggior parte dei casi questo non ha causato problemi in quanto gli oggetti da inviare sono risultati serializzabili per loro natura. L’unico caso problematico `e dato dagli Export generati dall’esecuzione Scafi. Un export deve necessariamente mantenere riferimenti a diverse classi interne di Scafi, ed alcune di esse non sono serializzabili.

`

E possibile definire una serializzazione personalizzata per un oggetto Java facendolo estendere dall’interfaccia Serializable e definendo al suo interno le funzioni

readObject e writeObject. writeObject specifica come serializzare l’oggetto in que- stione scrivendo i valori necessari alla sua ricostruzione in uno Stream. readObject `e la funzione complementare, che specifica come deserializzare un oggetto estraendo i valori da uno Stream.

Il problema dell’approccio appena descritto `e la necessit`a di poter modificare il sor- gente dell’oggetto da serializzare. Nel caso specifico, l’oggetto problematico `e Export, definito all’interno di Scafi, quindi si `e impossibilitati a modificare il suo codice.

Per risolvere il problema `e stato necessario definire un ulteriore oggetto, chiamato ExportWrapper, funzionante da involucro di export, all’interno del quale specificare la serializzazione di Export attraverso i campi e le funzioni messe a disposizione.

La parte da serializzare di un export (figura 4.7) contiene un insieme di coppie formate da percorso (Path) e valore. Un percorso `e formato da un insieme (anche vuoto) di slot. Uno slot pu`o essere di una di cinque tipologie: Nbr, Rep, Scope, FoldHood e FunCall.

4.1 Sotto-sistema Server 4. Implementazione

Figura 4.7: Struttura di un Export

La serializzazione `e stata definita navigando nella struttura dell’Export, prima scor- rendo le path, poi gli slot di ogni percorso, salvando di man in mano i valori necessari alla deserializzazione dell’oggetto, La deserializzazione, computata dal ricevente, avviene in maniera complementare alla serializzazione, leggendo i valori salvati in nello stesso ordine con il quale erano stati scritti.