Applicazioni utente iTetris

Le interazioni fra le applicazioni ed iCS si basano su un meccanismo che utilizza subscription e result container. In generale una applicazione contiene algoritmi che utilizzano i dati ricevuti da iCS e restituiscono risultati che possono essere riutilizzati dalla stessa o da altre applicazioni, oppure scatenare azioni nella simulazione di rete o veicolare (ad esempio cambiare il percorso di una vettura a seguito di una notifica di un ingorgo).

Le sottoscrizioni rappresentano l’unico meccanismo con cui l’applicazione può comunicare con iCS: questo componente è utilizzato per riceve ed inviare dati e per comandare l’esecuzione di azioni nei due simulatori. Una sottoscrizione può essere permanente oppure valere una volta sola, ad esempio la sottoscrizione per ricevere messaggi permette di ottenere dati fino a quando questa non viene esplicitamente can- cellata dall’applicazione; diversamente la sottoscrizione che permette di schedulare l’invio di un messaggio attraverso NS-3 è valida una sola volta, anche se l’applica- zione non la cancella esplicitamente iCS comanderà l’invio di un solo messaggio. Gli sviluppatori di iCS hanno messo a disposizione una serie di sottoscrizioni che soddi- sfano i casi d’uso più comuni ma c’è la possibilità di crearne di nuove per soddisfare gli specifici bisogni di una particolare applicazione. Purtroppo per poter sviluppare nuove sottoscrizioni occorre una conoscenza abbastanza approfondita del funziona- mento interno di iCS limitando l’usabilità di questa funzione.

Fra le sottoscrizioni predefinite di maggiore interesse vi sono quelle per sche- dulare l’invio di messaggi, per ricevere i messaggi correttamente trasmessi, per co- mandare il cambiamento del percorso di un veicolo e per ottenere informazioni sullo stato dei nodi. Anche l’interazione predefinita fra applicazioni utenti differenti av- viene tramite l’utilizzo di una particolare sottoscrizione che permette di accedere ai dati contenuti nel result container di un’altra applicazione. La comunicazione possi- bile attraverso questo meccanismo è abbastanza limitata, è infatti permesso il solo scambio dati, ma grazie alla grande libertà lasciata nello sviluppo delle applicazioni, è possibile implementare interazioni più complesse all’esterno di iCS, se necessario. In Figura 3.4 sono mostrati alcuni tipi di sottoscrizione.

I result container sono strutture dati all’interno di iCS che consentono di salvare informazioni generate dalla applicazione. Queste informazioni possono essere riuti- lizzate dall’applicazione stessa oppure possono servire per lo scambio di dati fra ap- plicazioni diverse. I result container sono molto importanti nel caso più applicazioni

41

necessitino di comunicare fra di loro, infatti sono l’unico strumento messo a disposi- zione da iCS per eseguire questo tipo di operazione.

Questo componente fa parte di iCS ma è sviluppato dal programmatore dell’ap- plicazione in modo che sia possibile personalizzarlo secondo le proprie necessità. Pur- troppo è necessario che lo sviluppatore conosca in modo approfondito il funziona- mento interno di iCS per personalizzarne il comportamento. iTETRIS, come nel caso delle sottoscrizioni, fornisce alcuni result container predefiniti che coprono i casi d’uso più comuni, in particolare è presente una implementazione generica che per- mette all’applicazione di salvare e recuperare dati di vario tipo ed una implementa- zione vuota utile per quelle applicazioni che non sono interessate ad utilizzare questo componente.

Le possibilità offerte dai result container non solo limitate al solo salvataggio di dati, è possibile implementare funzionalità più avanzate: il suo posizionamento in iCS permette di avere accesso alle logiche interne della piattaforma e può quindi essere programmato per agire per conto di un’applicazione comandando azioni a seguito di particolari eventi. Ad esempio un result container potrebbe essere incaricato dall’ap- plicazione di ricevere i messaggi che confermano la ricezione di una trasmissione in- viata ad un altro nodo.

42

L’esecuzione delle applicazioni avviene ad ogni passo di simulazione: iCS itera la correzione di nodi che stanno partecipando alla simulazione nello step attuale e per ognuno di questi viene comandata l’esecuzione di ogni applicazione. In modo simile agli step di simulazione anche l’esecuzione di un’applicazione è suddivisa in passi differenti come mostrato nella Figura 3.5. Queste fasi sono ripetute in ogni applica- zione per ogni nodo. In seguito sono illustrati i vari passi.

Richiesta sottoscrizioni: iCS chiede all’applicazione se vuole creare nuove sottoscri- zioni per il nodo corrente, l’applicazione può rispondere in modo negativo oppure con una nuova sottoscrizione. iCS continua a richiedere nuove sottoscrizioni fino a quando l’applicazione non risponde in modo negativo. Se viene richiesta una sottoscrizione per comandare un’azione all’interno di uno dei simulatori, ad esempio l’invio di un messaggio, iCS provvede subito a schedulare il comando richiesto, che sarà però ese- guito al passo di simulazione successivo.

Cancellazione sottoscrizioni: iCS itera fra tutte le sottoscrizioni che l’applicazione ha richiesto il nodo corrente. Per ognuna l’applicazione può decidere se mantenerla attiva oppure se cancellarla.

Figura 3.5: Ciclo di esecuzione di una applicazione ripetuto

43

Ricezione dei dati sottoscritti: per ogni sottoscrizione attiva nell’applicazione per il nodo attuale, iCS consegna i nuovi risultati, se presenti. Ad esempio vengono conse- gnati i messaggi ricevuti oppure le conferme della schedulazione di un messaggio. Non tutte le sottoscrizioni prevedono la restituzione di dati.

Notifica dei risultati: questa fase è utilizzata da particolari result container per noti- ficare l’applicazione del verificarsi di certi eventi. Un result container potrebbe, ad esempio, essere delegato alla ricezione di particolari messaggi da parte dell’applica- zione: in questa fase le comunica quali messaggi ha ricevuto. Non tutti i result contai- ner restituiscono dati.

Esecuzione dell’applicazione: quest’ultima fase permette di eseguire gli algoritmi presenti nell’applicazione per il nodo attuale, dopo aver ricevuto tutti i dati che l’ap- plicazione aveva richiesto. Alla fine dell’esecuzione l’applicazione può restituire dei risultati che iCS salverà nel result container.

Questa architettura è stata sviluppata con l’intenzione di imporre meno vincoli possibili agli sviluppatori di applicazioni, infatti l’unico requisito è quello di dover aprire una socket IP per la comunicazione. Purtroppo il comportamento della inter- faccia utente offerta da iCS è molto differente rispetto al modello classico offerto da altri simulatori e questo complica lo sviluppo dei applicazioni per questa piattaforma.