Comunicazione

Abbiamo visto come `e strutturato il framework ULLA e come sono stati implementati i moduli a supporto del livello LLA per la SDR CalRadio.

Vediamo ora, come si presenta l’architettura di ULLA, arricchita del modulo calradio LLA e come avviene la comunicazione con il device CalRa-dio.

La premessa, essenziale per comprendere l’architettura di Figura 2.7, `e che il device CalRadio, non `e un dispositivo hardware integrato nel pc, come potrebbe essere una scheda Atheros PCI.

Come verr`a specificato meglio nel prossimo capitolo, CalRadio `e una ra-dio stand-alone, dotata di un proprio sistema operativo. Si potrebbe pensare

Figura 2.7: Architettura del framework ULLA con il modulo calradio LLA

quindi di utilizzare il framework ULLA, direttamente su CalRadio, ma ve-dremo che questo non `e possibile a causa dell`’hardware e del kernel adottati da CalRadio. Quello che viene fatto, `e collegare mediante un’interfaccia ethernet, CalRadio con il pc che fa hosting al framework ULLA.

Viene quindi a delinearsi una comunicazione clien-server tra ULLA e CalRadio, per lo scambio di messaggi.

Tutto questo non limita le potenzialit`a di CalRadio, anzi da un certo punto di vista le estende: basti pensare alla possibilit`a di posizionare il de-vice ovunque si voglia, grazie alle dimensioni contenute del dispositivo (molto inferiori a quelle di un pc). Un altro vantaggio offerto da quest’architettura, `e la possibilit`a di utilizzare CalRadio su qualunque piattaforma, con il solo limite che questa abbia installato il framework ULLA. Invece, se CalRadio fosse un dispositivo integrato in un pc, bisognerebbe garantire la compat-ibilit`a con l’hardware e i driver del dispositivo. Ancora si pu`o vedere che CalRadio non pu`o essere collegata direttamente al pc con ULLA ma allo stesso modo potrebbe essere collegata ad un qualunque pc, in qualunque lu-ogo; si pensi ad esempio ad una rete di medie dimensioni: se calradio fosse collegata direttamente al pc con ULLA servirebbero n-pc per monitorare n-punti di questa rete. Viceversa, con questa architettura, baster`a un uni-co pc uni-con installato ULLA e n-device CalRadio disseminati nella rete, che comunicano tutti con il medesimo nodo. In questa maniera, si centralizza il framework e si distribuiscono i dispositivi osservatori, semplificando cos`ı

2.9. CONTRIBUTO 67

l’aggregazione delle informazioni, senza contare la semplificazione in termini di gestione.

Pertanto quest’architettura, accresce la flessibilit`a e la modularit`a dell’in-tero environment.

Nell’ambito della tesi, ULLA era in esecuzione su un pc di fascia media, con sistema operativo Linux Gentoo, con kernel alla versione 2.6.23.17. Il fat-to di utilizzare un pc per l’esecuzione del framework ULLA, `e dovufat-to in parte alle limitazioni dell’hardware CalRadio e in parte per poter supportare in mo-do pi`u efficiente lo storage e l’elaborazione delle statistiche rilevate, tramite un motore cognitivo, come pu`o essere il CRM di ARAGORN. Difatti, il salvataggio delle statistiche pu`o avvenire avvalendosi di un DataBase, come ad esempio MySQL, il quale necessita sia di spazio fisico, sia di performance elaborative.

Premesso tutto questo, vediamo nel dettaglio come funziona la comuni-cazione tra il modulo di ULLA e il device CalRadio.

Una volta che una richiesta da parte di un’applicazione arriva al livello LLA dell’architettura, tale modulo si occupa di specializzare la richiesta generica al device astratto corretto, nel nostro caso al LP calradio LLA. A sua volta, il modulo decide se inoltrare la richiesta verso il modulo calradio LLA lp op-pure verso calradio LLA link. Per semplicit`a nell’architettura di Figura 2.7, si parla del solo modulo calradio LLA.

Quindi il modulo prende a carico la richiesta, e l’inoltra, in forma di ioctl all’applicazione client. Questa, semplicemente creer`a un pacchetto UDP e lo invier`a ad una corrispondente applicazione server su CalRadio la quale a sua volta decodificher`a il pacchetto e invier`a un’ioctl verso il kernel di Cal-Radio per eseguire l’operazione richiesta. Una volta che i dati richiesti sono disponibili, questi verranno inviati tramite l’applicazione server al client (lato ULLA), che elaborer`a i risultati ottenuti. Per quanto riguarda l’applicazione server e la gestione da parte di CalRadio delle ioctl, si rimanda al capitolo successivo.

L’applicazione client, che opera in user space, deve comunicare con il modulo del kernel calradio LLA per il trasferimento dei dati. Questa comu-nicazione tra i due software, avviene con l’ausilio di un character device 3

per la ricezione dei risultati, mentre per l’invio delle richieste, vengono viene usato il meccanismo di ioctl.

L’implementazione, prevede che l’applicazione client debba solamente occuparsi dell’invio e della ricezione dei dati. Viceversa, il modulo

calra-3Un character device `e un file di Linux che permette la comunicazione tra un processi. Quello I device in Linux, sono distinti in tre categorie: character, network e block.Per maggiori informazioni sull’implementazione e l’utilizzo dei device e della comunicazione tra processi nel sistema Linux, si faccia riferimento a [21]

dio LLA, deve tener conto delle temporizzazioni necessarie per cui CalRadio elabori le richieste e restituisca i risultati. . .

Visto che il modulo di ULLA opera in kernel space, `e impensabile che questo resti in attesa di una risposta finch`e CalRadio non ha elaborato i dati. Quello che viene fatto nella pratica `e di schedulare l’esecuzione del modulo, dopo un istante temporale pari al tempo stimato per l’elaborazione dei dati da parte di CalRadio e la comunicazione. Per rendere questa tecnica pi`u consistente, il meccanismo funziona nel seguente modo: il modulo viene schedulato dopo il tempo designato; se il dato richiesto `e disponibile presso il character device, questo viene letto. Altrimenti, il modulo viene schedulato altre n volte ad istanti temporali ravvicinati. Questo viene fatto per essere tolleranti ad eventuali ritardi nella comunicazione client-server. Nel caso che, dopo le n-retry i risultati non siano ancora disponibili, il modulo segnala un errore e smette di interrogare il character device.