Integrazione di uno smartphone con una stazione multimediale attraverso una rete Bluetooth

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Integrazione di uno smartphone con una stazione multimediale attraverso una rete Bluetooth"

Transcript

1 POLITECNICO DI TORINO III Facoltà di Ingegneria dell informazione Laurea Specialistica in Ingegneria Telematica Tesi di Laurea Specialistica Integrazione di uno smartphone con una stazione multimediale attraverso una rete Bluetooth Realizzazione di un client VoIP per terminale mobile Relatore: Dott. Fulvio Corno Candidato: Christian GIORDANO Supervisore Aziendale Dott. Ferdinando Ricchiuti Aprile 2007

2 Sommario Il lavoro che viene presentato si pone l obiettivo principale di mostrare in maniera dettagliata l attività svolta durante il periodo di tesi presso il CSP - Innovazione nelle ICT, ed approfondirne gli aspetti teorici che supportano l attività svolta. Il progetto BlueVoice realizzato si compone di un applicazione per smartphone che simula una chiamata telefonica e, mediante una connessione Bluetooth, veicola il traffico voce e le opportune informazioni di segnalazione ad una stazione multimediale, ovvero un PC su cui è presente un software VoIP che da un lato agisce da server Bluetooth per accettare le richieste dei cellulari, e dall altro è il punto terminale di una chiamata VoIP. In questo modo è possibile sfruttare le potenzialità e i vantaggi offerti dai servizi di voce su Internet, pur utilizzando uno strumento comune come un telefono cellulare. Lo studio effettuato è partito, negli scopi iniziali, con l obiettivo e l approccio di un analisi tecnica sulle possibilità di realizzazione dell idea e si è conclusa con un prototipo funzionale, nonostante qualche limite che non ne pregiudicano comunque la fattibilità. Nel presente documento saranno perciò descritti gli obiettivi, le scelte progettuali e l implementazione realizzata durante il periodo di ricerca. Al termine sarà presentata una valutazione finale d insieme del lavoro svolto e verranno riportate le conclusioni con relative considerazioni sugli utilizzi futuri del progetto. I

3 Ringraziamenti Ringrazio il Politecnico di Torino per la formazione accademica che ho ricevuto, l istituto di ricerca CSP, il mio relatore Fulvio Corno, ed il mio tutore aziendale Ferdinando Ricchiuti, per l aiuto e la guida che mi hanno fornito durante lo sviluppo della mia tesi. Un sentito ringraziamento va inoltre ai miei genitori, che, con il loro incrollabile sostegno morale ed economico, mi hanno permesso di raggiungere questo traguardo. II

4 Indice Sommario Ringraziamenti I II 1 Introduzione 1 2 Istituto di ricerca CSP Introduzione Cos è il CSP Compagine societaria Organizzazione Innovazione Progettazione Reti Sociali Tecnologie Attività Ubicazione Piattaforma di Sviluppo Introduzione Java vs Symbian Java 2 Micro Edition Java rincorre Symbian III

5 3.3 Symbian OS Symbian C Architettura del Sistema Operativo Serie Programmare con Symbian Processo di sviluppo Applicazioni Symbian Convenzione dei nomi Stringhe e descrittori Gestione delle eccezioni Gestione degli eventi asincroni Scelte implementative Tecnologie di comunicazione Introduzione Bluetooth Topologia della rete Comunicazione Pila Protocollare Librerie BlueZ VoIP Differenze con la telefonia tradizionale Qualità di servizio Protocolli VoIP OPAL Analisi e design architetturale Introduzione Contesto applicativo Scenario applicativo per cellulari IV

6 5.3 Specifiche del progetto Modalità Walkie-Talkie Visione generale del progetto BlueVoice Applicazione lato client Applicazione lato server Requisiti progettuali Ritardi e jitter Vincoli per la connessione Bluetooth Aspetti di usabilità Implementazione del progetto Introduzione Architettura del progetto Classi client-side Struttura server-side Analisi di una chiamata Inquiry e connessione Bluetooth Streaming della voce Protocollo di segnalazione Gestione del registro delle chiamate Valutazioni finali Introduzione Considerazioni generali Limiti tecnologici e problemi Full duplex Qualità dell audio Virtualizzazione della scheda audio Priorità delle chiamate Limitata portabilità V

7 8 Conclusioni 142 Bibliografia 145 Sitografia 146 VI

8 Elenco delle tabelle 3.1 Tipi fondamentali in Symbian OS Tabella di confronto ritardi tra standard telefonici e applicativi VoIP VII

9 Elenco delle figure 2.1 Sede CSP all Environment Park Sede CSP in Villa Gualino Configurazioni e profili di J2ME Architettura di Symbian v8.0a OS Symbian OS: La Serie 60, UIQ e la Serie Generazione dei file di progetto specifici mediante file generici Symbian Framework applicativo Archiutettura applicativa e MVC Due piconet disposte a formare una scatternet Stati di un dispositivo Bluetooth Stack protocollare Bluetooth Emulazione di porte seriali Interazione nel protocollo SDP Visione generale di BlueZ Diagramma dei principali moduli di OPAL Scenario di utilizzo di BlueVoice Architettura generale di client e server BlueVoice Schema logico della funzionalità full-duplex Diagramma di flusso del ciclo di vita di una chiamata Schema di chiamata BlueVoice-telefono VoIP Rappresentazione della tratta totale tra utenti finali Diagramma UML dell applicazione BlueVoice VIII

10 6.2 Diagramma UML della pubblicazione servizi a lato server e ricerca e connessione di dispositivi Bluetooth a lato client Rappresentazione grafica della struct TDeviceData che definisce un dispositivo remoto Fase 1: Ricerca dispositivi e servizi ; Fase 2: sistema connesso Rappresentazione logica del buffer circolare e relative caratteristiche Evoluzione temporale del buffer circolare Ritardi minimo e massimo introdotti dal buffer (rappresentazione fisica). 131 IX

11 Capitolo 1 Introduzione L attuale sviluppo delle applicazioni per la telefonia su Internet è di notevole interesse per i principali sviluppatori di software, in quanto le attuali tecnologie di comunicazione telefonica permettono di avere costi irrisori o addirittura nulli per l utente finale e lasciano perciò presupporre un mercato promettente ed in continua crescita ed evoluzione. Recentemente infatti si è assistito ad un rapido sviluppo di mercato della telefonia VoIP e dei servizi ad essa collegati, reso possibile dalla crescente diffusione delle connessioni Internet veloci, dette anche a banda larga, con abbonati che inviano e ricevono chiamate in modo del tutto analogo a quello con cui il servizio veniva erogato attraverso la vecchia rete analogica commutata. Allo stato attuale, la telefonia VoIP è destinata ad affiancarsi a quella analogica tradizionale piuttosto che a rimpiazzarla, nonostante alcune delle limitazioni attuali quali, ad esempio, l impossibilità di instradare automaticamente le chiamate di emergenza. Bisogna aggiungere che la realizzazione di client VoIP che sfruttano una comunicazione wireless è di estrema attualità in quanto tra gli sviluppi tecnologici dello standard Bluetooth figurano in prima linea i servizi di voce sul protocollo IP. Oggi tale tecnologia viene già impiegata nei microfoni usati come estensioni wireless dei sistemi audio dei cellulari e dei PC e, dato l incremento in popolarità e nell uso di VoIP, Bluetooth costituisce una parte fondamentale dello sviluppo di tipo telefonico volto all utilizzo dei telefoni cordless e cellulari per effettuare una chiamata VoIP. 1

12 1 Introduzione Ad oggi esiste un innumerevole quantità di offerte per utilizzare in modo semplice la telefonia su Internet, ed i prodotti spaziano dei cosiddetti kit VoIP Bluetooth ai telefoni VoIP. Il kit comprende un auricolare o headset ed un adattatore USB per PC, entrambi Bluetooth, che permette di collegare i due componenti in modalità senza fili, e vede tra i principali produttori nomi come Sony Ericsson e Motorola. Di numero più ristretto sono i telefoni VoIP, cioè soluzioni ad-hoc che integrano in genere tutte le funzioni classiche di un telefono e che vengono collegati al PC tipicamente mediante la presa USB o grazie ad una connessione Bluetooth (attualmente solo il ClearSky della TRENDNET). L idea del progetto nasce da un esigenza per l utente di utilizzare i due servizi telefonici, quello veicolato sulla rete Internet e quello che sfrutta l infrastruttura telefonica GSM o UMTS, servendosi del medesimo apparecchio telefonico, in modo da facilitare e rendere accessibile a chiunque le potenzialità della nascente tecnologia VoIP. La parola d ordine che sta alla base del lavoro e che ne permea tutta la realizzazione è quindi la trasparenza, poiché idealmente il fruitore del servizio telefonico non è tenuto a conoscere i dettagli di basso livello del mezzo usato per trasmettere la propria voce. L indistinguibilità tra le due modalità ne accresce indubbiamente l accessibilità in quanto espande il range di utenti oltre ai soli esperti dell ambito, e risulta appetibile perché permette di abbassare considerevolmente i costi. Il progetto ha portato alla realizzazione di un applicazione chiamata BlueVoice ed ha come scopo principale la verifica di fattibilità di questa particolare ipotesi di utilizzo del telefono cellulare all interno di uno scenario che vede il suddetto come punto finale di una chiamata VoIP inoltrata da una stazione fissa al dispositivo mediante una connessione wireless Bluetooth. Dall esito di questo studio si vuole fornire l implementazione di un prototipo che ne dimostri l attuabilità e gli eventuali limiti, in modo da comprendere quali punti necessitino maggiormente di migliorie in un eventuale passo successivo del lavoro. Il periodo di tesi comprende, in una fase propedeutica, lo studio preventivo dei meccanismi di funzionamento di Bluetooth, in quanto mezzo scelto per la comunicazione e quindi per l integrazione del dispositivo mobile con la stazione fissa, e l analisi delle piattaforme più adatte per realizzare un prodotto rispondente alle specifiche iniziali e coerente 2

13 1 Introduzione con gli scopi del progetto. In particolare la valutazione della piattaforma è stato un processo di fondamentale importanza per l usabilità e l efficienza del software finale, ed ha accompagnato una significativa parte della durata della tesi. Al termine di questa fase ha avuto luogo quella implementativa che ha portato alla progettazione e realizzazione del sistema in grado di integrare il telefono e la stazione multimediale. Essendo un lavoro di ricerca non è possibile prevedere a priori l attuabilità concreta dell idea iniziale proposta, ed è per questo che il processo di sviluppo è proceduto per passi, in modo da assicurare la fattibilità di ogni tappa intermedia. Si è pertanto realizzato il codice che implementa il client posto sul telefono cellulare. Esso deve essere in grado di ricercare dispositivi Bluetooth nel raggio di ricerca e stabilire una connessione con uno di essi, registrare la voce dell utente ed inviarla all altra stazione in streaming, e contemporaneamente deve ricevere i pacchetti voce dall altro dispositivo per poterli riprodurre e farli ascoltare all utente. Ovviamente tutte queste operazioni devono essere gestite e completate da un protocollo di segnalazione che fornisca le necessarie primitive di controllo per inoltrare, accettare, rifiutare e terminare una chiamata voce, esattamente come succede nella telefonia classica a cui si è abituati. Come già affermato la totale trasparenza rispetto al normale servizio telefonico offerto da GSM vuole essere uno degli intenti principali dell applicazione, in modo da rendere la fruizione del software semplice ed immediata. Una prima tappa a cui si è giunti è un applicazione che permette di stabilire una chiamata voce tra due telefoni cellulari usando la connessione Bluetooth. La modalità di utilizzo è molto simile a quella del Walkie-Talkie, con la differenza che non si ha un meccanismo Push-to-Talk, cioè un metodo di comunicazione lungo linee half-duplex 1 che usa un sistema in grado di commutare dalla modalità di trasmissione a quella di ricezione, bensì un meccanismo del tutto simile ad una telefonata tradizionale. Quest ultima non avrebbe quindi costi di traffico ma la portata decisamente ridotta, tipica degli standard wireless per reti personali come Bluetooth. 1 L half-duplex è una modalità di invio e ricezione di informazioni digitali in cui è possibile trasmettere in entrambe le direzioni, ma non contemporaneamente. 3

14 1 Introduzione Questo ostacolo è superato nella tappa successiva dell implementazione, mediante l interazione con la stazione multimediale, ovvero una macchina su cui è attivo un programma per chiamate VoIP, che porta al compimento conclusivo dell applicazione. In questo modo si ha il congiungimento del terminale mobile con la rete Internet e si allunga la tratta end-to-end in modo da risultare tra i due terminali mobili connessi ai PC, piuttosto che tra i due PC. In definitiva, nei disegni di progetto, il sistema permetterebbe di utilizzare un cosiddetto telefono intelligente, ovvero uno smartphone come terminale per chiamate voce, sia in ingresso che in uscita, verso la stazione multimediale. Le chiamate vengono poi inoltrate dalla stazione multimediale attraverso la rete Internet, facendo uso dei diversi protocolli standard per la telefonia su IP (quali ad esempio SIP e H.323). Un sistema di questo tipo è molto utile per usare uno strumento classico come il telefonino per poter comunicare attraverso sistemi innovativi e più economici disponibili grazie alla banda larga. 4

15 Capitolo 2 Istituto di ricerca CSP 2.1 Introduzione Il periodo di tesi che ha visto la progettazione e la realizzazione del lavoro presentato precedentemente e trattato nel dettaglio nei capitoli successivi, ha avuto luogo presso il CSP - Innovazione nelle ICT, la struttura di Innovazione e ricerca della pubblica amministrazione piemontese nel campo delle tecnologie della Società dell Informazione. In questo capitolo viene fornita una rapida presentazione dell istituto, della sua organizzazione interna e della struttura dei vari laboratori. Per ulteriori approfondimenti si rimanda al sito ufficiale [1]. 2.2 Cos è il CSP Avviato come una piccola struttura attiva all interno dei locali storici del CSI Piemonte, è cresciuto in modo significativo e oggi occupa stabilmente 40 persone in due diverse sedi. CSP eroga inoltre ogni anno tra le 25 e le 30 borse di studio in collaborazione con gli Atenei locali, ospitando più di 20 stage e tesi, a cui si aggiungono oltre 40 collaborazioni professionali per lo svolgimento delle attività dei diversi settori. CSP occupa ogni anno oltre 140 persone in maggioranza giovani ricercatori attivi nei 5

16 2 Istituto di ricerca CSP progetti di ricerca sviluppati in cooperazione con le Università e nei programmi di innovazione per i propri clienti. Ha annualmente oltre 70 contratti di consulenza e sperimentazione per oltre 25 soggetti pubblici e privati. Dal 1998 ad oggi il CSP ha sviluppato la nuova missione affidata dai soci in seguito alla conclusione dell esperienza di CSP quale Centro Supercalcolo del Piemonte. Il valore dell operatività è cresciuto costantemente nel corso degli ultimi anni, attestandosi, nel corso del 2006, a oltre 4,5 milioni di euro, risultato di circa 100 diverse attività svolte per più di 35 clienti, con più di 50 accordi di collaborazione attivi con Atenei, Centri di ricerca, Enti pubblici. CSP è Laboratorio di ricerca MIUR, certificato UNI EN ISO 9001:2000, e fa parte di numerose associazioni e consorzi tra cui il Consorzio World Wide Web (W3C), e il comitato del consorzio europeo Galileo. 2.3 Compagine societaria I soci di CSP sono: Politecnico di Torino Università degli Studi di Torino Comune di Torino CSI-Piemonte Unione Industriale di Torino Confindustria Piemonte Iride Energia S.p.A. CSP - Innovazione nelle ICT Società consortile a responsabilità limitata in forma abbreviata CSP s.c. a r.l. le cui caratteristiche sono di seguito elencate: 6

17 2 Istituto di ricerca CSP Natura giuridica : Società Consortile a responsabilità limitata Capitale sociale : e ,00 Data di costituzione : 02/03/1989 Data di inizio attività : 27/05/1991 Durata : 31/12/ Organizzazione CSP è organizzato in base a competenze specifiche e gruppi di lavoro che contemplano alcuni ambiti di attività principali, all interno dei quali si articola l operatività specifica di aree, gruppi e laboratori. La dimensione collegiale del lavoro, è integrata da partnership con soggetti pubblici e privati e da una forte sinergia con il mondo accademico a livello locale, nazionale e internazionale. Al fianco della Direzione generale che ha funzioni di gestione e indirizzo sull attività complessiva di CSP operano le aree descritte nelle seguenti sezioni Innovazione Idea e propone, coordina e gestisce programmi e progetti di innovazione a livello locale, nazionale e internazionale, promuovendo la collaborazione trasversale di aree e direzioni. A ciò si aggiunge il coordinamento e la gestione delle attività di marketing rivolte sia al settore pubblico sia privato, le attività di comunicazione interna ed esterna, lo sviluppo di progetti web e di gestione delle communities legate ai progetti, lo studio e il benchmarking dello sviluppo della Società dell Informazione a livello locale e internazionale Progettazione Si occupa di proporre e coordinare progetti di carattere strettamente tecnologico verso i soggetti locali, nazionali e internazionali del settore pubblico e privato. Il supporto 7

18 2 Istituto di ricerca CSP operativo alle altre aree di CSP viene attuato utilizzando le competenze che derivano dalle attività di ricerca dei laboratori, coordinando e gestendo la fase realizzativa dei progetti ed esportando le stesse competenze per la gestione delle infrastrutture tecnologiche di CSP. Tra gli obiettivi, l incremento dei progetti verso il settore privato, verso i prospect e il rafforzamento dei rapporti con le public utilities, con competenze che spaziano dalla gestione di Infrastrutture e tecnologie, all internetworking, al testing di piattaforme tecnologiche innovative, alla gestione sistemistica alla sperimentazione su Grid e architetture distribuite Reti Sociali Concentra la propria attività sulla sperimentazione e progettazione nell ambito della condivisione della conoscenza, a cui si aggiungono e-business, analisi e monitoraggio dello sviluppo della Società dell Informazione e competenze sul fronte dei contenuti multimediali per la banda larga. Tra gli ambiti di specializzazione spiccano lo sviluppo di modelli di formazione a distanza attraverso la gestione di comunità di conoscenza e l analisi di piattaforme tecnologiche per la gestione del lavoro cooperativo e dell e-learning, lo sviluppo di progetti legati all universo del web 2.0, e la loro sperimentazione applicativa per lo sviluppo locale e il mondo della scuola e dell accademia. I laboratori che svolgono la propria attività in cooperazione con l Università di Torino sono: 1. Keilab - Knowledge exchange laboratory 2. SmartLab - Social Media Application Research Laboratory Tecnologie Indaga e studia le tecnologie di base, infrastrutturali e applicative, e i nuovi processi resi percorribili dal loro utilizzo. La Direzione si configura come un incubatore di attività 8

19 2 Istituto di ricerca CSP per l applicazione della ricerca nel senso stretto di luogo in cui, attraverso laboratori tematici, si apprendono i fondamenti scientifici e tecnici delle tecnologie emergenti e si sviluppano attività pratiche calandole in scenari reali costruiti su case study attuali e ipotizzati per il prossimo futuro. La Direzione è strutturata sulla base di quattro laboratori di ricerca permanenti: 1. DTTLab - Digital Terrestrial Television Laboratory 2. SecureLab - ICT Security Laboratory 3. InLab - Integrated Networks Laboratory 4. W3Lab - World Wide Web Laboratory 2.5 Attività CSP agisce a livello locale, nazionale e internazionale costruendo attività di ricerca applicata, accordi e progetti di cooperazione con enti pubblici, amministrazioni locali e grandi imprese private. La dimensione locale di CSP è caratterizzata da attività di sperimentazione e trasferimento tecnologico di soluzioni innovative e di sviluppo di progetti nell ambito di programmi pluriennali dal forte contenuto sperimentale. Si tratta di attività svolte nel quadro di Convenzioni e accordi pluriennali firmate con la Pubblica Amministrazione locale - Regione, Province e Comuni -. A livello nazionale CSP svolge attività di trasferimento tecnologico e sperimentazione di soluzioni innovative nell ambito di convenzioni firmate con la Pubblica Amministrazione su tutto il territorio nazionale con progetti che spaziano da partner Regionali, a partecipate ai Ministeri. Sul piano internazionale, CSP partecipa a progetti co-finanziati dalla Commissione Europea e ad associazioni e gruppi di lavoro per la diffusione dell innovazione e lo sviluppo di una pubblica amministrazione su base europea. 9

20 2 Istituto di ricerca CSP In rappresentanza della Regione Piemonte, CSP fa parte di ERISA, la rete delle Regioni Europee Innovative, e partecipa al progetto IANIS+, la principale rete europea di regioni impegnate nell ambito della diffusione della Società dell Informazione. 2.6 Ubicazione Sede Legale e Operativa Environment Park Laboratori A1 via Livorno, Torino Tel Fax Seconda Sede Operativa Villa Gualino Viale Settimio Severo, Torino Tel Fax

21 2 Istituto di ricerca CSP Figura 2.1. Sede CSP all Environment Park Figura 2.2. Sede CSP in Villa Gualino 11

22 Capitolo 3 Piattaforma di Sviluppo 3.1 Introduzione Una volta stabilite le specifiche e gli obiettivi teorici che vogliono essere raggiunti dal progetto, ci si è subito dovuto scontrare con una serie di problemi legati alla realizzazione pratica e all implementazione del codice relativo. Innanzitutto una buona parte del periodo di tesi è stata dedicata allo studio delle due principali tecnologie che permettono di realizzare il software in questione, cioè Java 2 Micro Edition e il sistema operativo Symbian. Questo indubbiamente ha rappresentato uno degli scogli più difficili da superare poiché entrambe le piattaforme presentano vantaggi e svantaggi su aspetti diversi, trasformando così il problema nella ricerca del giusto compromesso tra efficienza e portabilità del software. Le sezioni successive sono una descrizione dettagliata di quanto appreso in questa fase della tesi, una spiegazione delle potenzialità e dei limiti di entrambi questi due approcci che caratterizzano il mondo dello sviluppo delle applicazioni per cellulari. A queste informazioni si è giunti, oltre che mediante un approfondito studio della documentazione in merito a tali tecnologie, anche attraverso una fase di test iniziali di confronto che hanno poi determinato la scelta definitiva. 12

23 3.2 Java vs Symbian 3 Piattaforma di Sviluppo Lo sviluppo di applicazioni su dispositivi wireless, come visto nel paragrafo precedente, può essere effettuato utilizzando diverse tecnologie. Per fornitori e programmatori è costante il confronto con le applicazioni basate su Symbian e quelle J2ME. A grandi linee si può dire che Symbian è un potente sistema operativo utilizzato da diversi telefonini dell ultima generazione, mentre J2ME (Java 2 Micro Edition) non è altro che una versione ridotta del Java 2 Standard Edition. Sviluppare applicazioni Symbian equivale a produrre software dall elevata potenzialità ma solo per dispositivi con sistemi operativi Symbian, mentre, sviluppare applicazioni J2ME, equivale a produrre software certamente meno potente ma in grado di funzionare su tutti i dispositivi dove risiede una particolare Java Virtual Machine. Senza entrare troppo nel dettaglio si osserva che con Symbian si punta molto su potenza e flessibilità, mentre con J2ME si punta su portabilità e compatibilità. Generalmente su tutti i telefonini Symbian è presente una particolare Java Virtual Machine, ma non tutti i dispositivi che presentano al loro interno una Java Virtual Machine sono dotati di sistema operativo Symbian. Prima di entrare nell analisi delle differenze tra le due tecnologie, verrà data una descrizione delle caratteristiche strutturali di J2ME, soffermandosi in particolar modo sull evoluzione attraverso la quale tale piattaforma si è avvicinata di molto alle potenzialità di Symbian. Di seguito sarà affrontata una completa trattazione di Symbian, con particolare riguardo alla piattaforma e a tutta una serie di funzionalità utilizzate nel lavoro svolto Java 2 Micro Edition Java Micro Edition (noto anche come Java ME o J2ME), è un runtime e una collezione di API per lo sviluppo di software dedicato a dispositivi a risorse limitate come PDA, telefoni cellulari e simili. J2ME è la tecnologia più diffusa per lo sviluppo di giochi e utilities per i cellulari. 13

24 3 Piattaforma di Sviluppo Come le altre edizioni di Java, J2ME è una piattaforma portabile. Il suo funzionamento può essere emulato con un personal computer, cosa che semplifica l attività di sviluppo e di testing. La Micro Edition, progettata dalla Sun Microsystems, è il sostituto per una tecnologia simile chiamata PersonalJava, ed è diventata un popolare strumento di sviluppo poiché i software possono essere emulati sul PC e facilmente installati sul dispositivo. J2ME è solo una delle tre diverse edizioni (edition) di Java, che pur rimanendo basate grossomodo su virtual machine compatibili ed un insieme di API di base, si sono differenziate a seconda del loro target. Le edition sono state introdotte con il rilascio di Java2, e partizionano, per così dire, piattaforme, API, e strumenti di sviluppo in tre differenti gruppi ognuno dei quali indirizzato ad un ben preciso segmento di mercato: Java 2 Enterprise Edition (J2EE), fornisce un insieme di API per la realizzazione di architetture solide, complete e scalabili, dirette, soprattutto, ad applicazioni server; Java 2 Standard Edition (J2SE), rappresenta il nucleo del linguaggio Java ed è indirizzata allo sviluppo di applicazioni ed applet sul lato client; Java 2 Micro Edition (J2ME), studiata appositamente per dispositivi embedded e per l elettronica di consumo; J2ME non è indirizzata a singole piattaforme, come lo era PersonalJava ma, in generale, a tutto il settore embedded. La sua architettura e le sue specifiche sono ben delineate ed essa stessa è una versione standard di Java. Naturalmente il fatto che J2ME sia dedicata a tutto il mercato embedded non vuol certo dire che possa essere utilizzata con qualunque tipo di apparecchiatura e in qualunque contesto. La sua struttura modulare ed espandibile permette però di coprire una vasta gamma di piattaforme (apparati) embedded: dai PDA ai cellulari, dai navigatori satellitari a TV digitali con tutti i vantaggi che il linguaggio Java può portare. Uno degli aspetti più interessanti e apprezzati di Java è sempre stato il suo alto grado di portabilità e il suo livello di astrazione dall hardware, che J2ME mantiene ed estende ad un settore, quello dell elettronica di consumo, davvero ricco di piattaforme differenti. 14

25 3 Piattaforma di Sviluppo Architettura J2ME Le caratteristiche di modularità e scalabilità vengono garantite in J2ME attraverso i concetti di Configurazioni e Profili: Configurazioni - definiscono le caratteristiche di base del linguaggio Java e della Virtual Machine per un insieme di dispositivi, e forniscono un insieme di librerie di base comuni per più categorie di apparati (es. Cellulari, PDA, smartphone); Profili - si basano su una configurazione, ne estendono le funzionalità di base, fornendo API addizionali e tools di sviluppo per una particolare categoria di dispositivi (es. PDA). Le applicazioni scritte per un dato profilo sono portabili ed eseguibili su qualunque dispositivo che lo supporti; Le configurazioni, quindi, sono dirette ad un insieme di apparati e non ad una specifica categoria, mentre i profili sono qualcosa di più legato al dispositivo stesso. Prendendo come riferimento l intero settore embedded si può dire che, mentre le configurazioni eseguono un raggruppamento dei dispositivi in senso orizzontale, i profili lo fanno in senso verticale. Configurazioni In base alle caratteristiche dei vari apparati possiamo distinguere dispositivi a uso esclusivamente personale, mobili, che necessitano di connessioni a reti in modo non continuo e dispositivi condivisi, fissi, che necessitano di connessioni a reti in modo continuo. Nella prima categoria rientrano i telefoni cellulari, i pager, i PDA, cioè tutti quei dispositivi caratterizzate da un interfaccia utente molto semplice, ridotte disponibilità di memoria (tipicamente 128 KByte - 2 MByte), limitate capacità di elaborazione, basso consumo di energia e connessioni a reti di telecomunicazione di tipo wireless con modesta larghezza di banda. 15

26 3 Piattaforma di Sviluppo Per la seconda categoria sono tipici esempi apparecchiature come Web TV, telefoni capaci di accedere ad Internet, ricevitori televisivi satellitari, communicator, sistemi di navigazione per auto. Tutti questi dispositivi, essendo installati in modo fisso, non risentono dei tipici problemi dei dispositivi portatili (o addirittura tascabili) come peso, dimensioni e consumi di energia e possono, quindi, contare su dotazioni di memoria anche notevoli (da 2 MByte a 32 MByte), processori veloci e performanti e connessioni continue a reti con ampia larghezza di banda. Pur non essendo netto il confine che separa queste due categorie, è necessario tenere in considerazione alcune caratteristiche hardware fondamentali del dispositivo sul quale il software dovrà funzionare quali: - la potenza di calcolo e la disponibilità di memoria; - la presenza o meno di un display e le sue caratteristiche; - le tipologie di connessione a reti di TLC; È proprio sulla base di questi parametri che J2ME ha implementato le sue due attuali configurazioni, ossia: CLDC (Connected Limited Device Configuration) - è dedicata a dispositivi con memoria minima di circa 128 KByte (RAM e ROM), processori (RISC/CISC) a bit, basso consumo e funzionamento tipicamente a batteria, connessioni non continue a reti eterogenee, sovente di tipo wireless con larghezza di banda limitata (spesso uguale o inferiore a 9600 bps). La Virtual Machine prevista per questa configurazione è la KVM (Kilobyte Virtual Machine), ossia una macchina virtuale Java studiata per apparecchi con memoria totale dell ordine dei KByte (il core della KVM occupa da 32 a 80 KByte). CDC (Connected Device Configuration) - è studiata per dispositivi hardware che dispongono di almeno 2 MByte totali di memoria (RAM e ROM), processori a 16

27 3 Piattaforma di Sviluppo 32 bit, di connessioni persistenti a reti TLC con ampia larghezza di banda e interfacce grafiche anche molto sofisticate. La virtual Machine utilizzata per questa configurazione è la CVM (C Virtual Machine). La CLDC può essere considerata come una versione alleggerita della CDC. Le configurazioni forniscono un set minimo di librerie di base: alcune di queste costituiscono un sottoinsieme di package della Standard Edition altre, sono state realizzate appositamente per la Micro Edition. Profili Le funzionalità di base garantite dalle configurazioni però non bastano per realizzare un applicativo. Ad esempio la configurazione dedicata di un cellulare è la CLDC: questa ci mette a disposizione un insieme di librerie di base che permettono di utilizzare Java (java.lang), di gestire gli stream di I/O (java.io), ci fornisce tutta una serie di classi di utilità (java.util) e ci da la possibilità di comunicare (javax.microedition.io). Ma per operazioni come l iterazione con l utente, la realizzazione di interfacce grafiche, il salvataggio dei dati e la creazione dell eseguibile per cellulare a partire dal classico.java è chiamato a risponderne il profilo. Esso si occupa di gestire tutte quelle problematiche più strettamente collegate al tipo di apparato, come la gestione dei dispositivi di Input/Output, il salvataggio persistente dei dati nelle memorie non volatili, la realizzazione di UI e fornisce dei tool di sviluppo per una determinata categoria di dispositivi (in questo caso i cellulari). I profili si suddividono in base alla configurazione per la quale sono stati realizzati. Quelli attualmente previsti (non tutti attualmente disponibili) sono: 1. Configurazione CDC: Foundation Profile : profilo per dispositivi che richiedono una completa implementazione della Java Virtual Machine e includono quindi tutte le API della J2 Standard Edition; 17

28 3 Piattaforma di Sviluppo RMI Profile : questo tipo di profilo, come indicato dal nome, include un sottoinsieme di API RMI (Remote Method Invocation) della J2SE, in modo da garantire un certo grado di interoperatività con altre virtual machine sia J2ME sia J2SE; Personal Profile : è l estensione dell ambiente PersonalJava di Sun e garantisce una piena compatibilità con le applicazione sviluppate con le versioni 1.1.X e 1.2.X di PersonalJava Application Enviroment; 2. Configurazione CLDC : PDAP : il Personal Digital Assistant Profile è il profilo dedicato ai dispositivi palmari. Tali apparati devono avere almeno 512 KByte di memoria (RAM + ROM) e un display con risoluzione totale di almeno pixel; MIDP : il MIDP (Mobile Information Device Profile) è un profilo dedicato a dispositivi wireless come telefoni cellulari, smartphone e pager; Nella figura 3.1 sono raffigurate le configurazioni e i profili di J2ME. Figura 3.1. Configurazioni e profili di J2ME 18

29 3 Piattaforma di Sviluppo Java rincorre Symbian Negli anni J2ME ha subito un evoluzione che dimostra come essa sia andata spesso di pari passo con quella di Symbian OS a cui va asintoticamente avvicinandosi. Da subito l idea di un Java light, strumento con il quale diffondere applicazioni sul mercato di massa, risulta molto appetibile per i costruttori. Lo stesso consorzio Symbian si accorge della forza di J2ME e include il MIDP 1.0 nel Symbian OS v6.0 realizzato nel Ma, sebbene MIDP 1.0 avesse entusiasmato non poco la Wireless Java Community, fu subito evidente il collo di bottiglia di non poter accedere da una MIDlet 1 alle funzionalità tipiche degli smartphone, cosa che era possibile utilizzando le API Symbian. Inoltre la tanto sventolata portabilità, soprattutto con MIDP 1.0, fu un vantaggio solo teorico, in quanto passando da un modello ad un altro di terminale mobile, non solo si dovevano apportare modifiche a livello di UI, ma spesso una semplice connessione HTTP non funzionava più. Di conseguenza si cominciò a lavorare al MIDP 2.0 e ad una serie di API aggiuntive. Il MIDP 2.0 comincia ad essere uno strumento sufficientemente completo, in quanto offre un meccanismo di sicurezza, nuove UI API, Game e Audio API, Push Registry. Accanto al MIDP 2.0 package opzionali quali MMAPI (Mobile Media API), WMA (Wireless Messaging API), JABWT (Java API for Bluetooth Wireless Technology), offrono nuove funzionalità per il supporto di video e immagini e la gestione della videocamera, per inviare e ricevere SMS e per accedere allo stack Bluetooth. Tutte queste API opzionali insieme al MIDP 2.0 vengono offerte da Symbian OS v7.0. Da questo momento in poi lo sviluppo di nuove funzionalità su J2ME subisce un accelerazione, nascono di continuo nuove JSR 2 che mirano non solo a colmare il gap con le applicazioni native ma anche a rendere più facilmente programmabili alcune funzionalità. Nascono così Mobile 3D Graphics per la grafica tridimensionale, File Connection API per 1 Una MIDlet è un programma Java per dispositivi embedded, più specificatamente per la virtual machine Java ME. Generalmente tali programmi sono giochi e applicazioni per cellulari. 2 Le JSR, ovvero le Java Specification Request sono documenti formali che descrivono delle nuove specifiche proposte e tecnologie da aggiungere alla piattaforma Java. Una volta che tale JSR diventa finale e viene votato dalla JCP Executive Committee, essa fornisce un implementazione della tecnologia e un Kit di compatibilità della tecnologia per verificare le specifiche delle API. 19

30 3 Piattaforma di Sviluppo l accesso al file system, Personal Information Management per l accesso alle informazioni personali come la rubrica, Content Handler API, Web Services API (parsing XML, RPC messaging, SOAP), Security and Trust Services API (sicurezza, crittografia, firma digitale, accesso a Smart Card), SIP API (instant messaging, presence, chatting, gaming), WMA 2.0 (oltre agli SMS supporto anche per MMS), Location API, ecc. Le versioni 8.0 prima e 9.0 dopo del Symbian OS offrono man mano tutte queste API, funzionanti sopra la CLDC 1.1 VM. Del resto all interno dei gruppi di esperti che si occupano delle JSR J2ME, la maggioranza sono ormai rappresentanti del consorzio Symbian, Nokia in primis. Studiando l evoluzione delle performance di J2ME in funzione del Symbian OS si può vedere come le funzionalità di J2ME siano sempre maggiori col passare degli anni e con il progredire di Symbian, che risulta essere ormai il maggior aggregatore di risorse Java. Intanto le implementazioni Java risultano ora totalmente compatibili con le specifiche Java Technology for the Wireless Industry (JTWI, JSR 185). JTWI è un iniziativa del JCP per definire un set minimo di API e di funzionalità di cui ogni telefono deve disporre. La release 1 di questa specifica prevede che il set minimo comprenda MIDP 2.0, CLDC 1.0, WMA e MMA. Anche le performance delle applicazioni Java sono andate migliorando nel tempo, grazie alla compilazione adattativa dinamica, all accelerazione hardware degli interpreti di byte code, all ottimizzazione della grafica e dell interfaccia nativa. Allo stesso tempo anche le velocità di clock sono aumentate. In poche parole le performance di J2ME sono migliorate con l evoluzione del sistema operativo Symbian OS, di circa 40 volte rispetto a quelle originali. Recentemente Sun Microsystems ha annunciato che sono 250 milioni i telefoni nel mondo che supportano la tecnologia Java. Dopo quello che è stato detto si può riassumere quella che è la storia delle differenze, se si vuole di vantaggi e svantaggi, nello sviluppo di applicazioni J2ME e Symbian: inizialmente Symbian accanto alla flessibilità e alla potenza, caratteristiche di un sistema operativo, presenta il punto debole di una scarsa diffusione sul mercato di massa; d altro canto Java, grazie alla sua peculiare portabilità, si pone come veicolo di diffusione delle applicazioni mobili su moltissimi dispositivi. A 20

31 3 Piattaforma di Sviluppo creare difficoltà allo sviluppo di Java interviene da una parte l impossibilità di poter creare applicazioni che utilizzino le funzioni native del telefono, e dall altra il fatto che la portabilità è solo virtuale, a livello di UI i telefoni sono diversi tra di loro e le implementazioni proprietarie del MIDP risultano spesso differenti. Possiamo così sintetizzare i benefici che Symbian OS ha apportato a J2ME: 1. Robustezza : Symbian OS è pensato per essere attivo 24 ore al giorno, 7 giorni su 7. L integrità dei dati è il vantaggio maggiore dei telefoni Symbian. Java si poggia su queste solide basi. 2. Funzionalità : come detto prima molte delle funzionalità offerte da J2ME e implementate in diversi package sono incluse nel sistema operativo Symbian. 3. Performance : Symbian precarica le classi Java di sistema permettendo una diminuzione dei tempi di start-up delle applicazioni e rendendo disponibile alle applicazioni più memoria. Nel corso degli anni J2ME tende a realizzare ciò che per Symbian è già realtà e, anzi, laddove J2ME è supportato dal Symbian OS, si può notare come J2ME si avvantaggi dei progressi del sistema operativo. 3.3 Symbian OS Symbian OS è un sistema operativo aperto, prodotto dalla Symbian Ltd. e adottato come standard dalle principali aziende mondiali produttrici di dispositivi per la telefonia mobile (cellulari, smartphone, PDA). Il sistema operativo è stato progettato per supportare i requisiti specifici di trasporto dati per i dispositivi mobili di nuova generazione 2G, 2,5G e 3G. Le caratteristiche generali principali di Symbian OS sono la presenza di un microkernel a 32 bit robusto e adatto al multi-tasking con preemption (o diritto di prelazione 3 ) e al 3 Si dice che lo scheduling è con preemption quando un thread a più elevata priorità può interromperne 21

32 3 Piattaforma di Sviluppo multi-threading, il supporto integrato per la telefonia, diversi protocolli di comunicazione, un avanzato supporto grafico e un framework di basso livello per l interfaccia utente e una varietà dei cosiddetti application engine 4. Inoltre Symbian è un sistema operativo aperto, non nel senso di Open Source, in quanto il codice sorgente non è disponibile pubblicamente, ma nel senso che le API sono documentate e liberamente fornite ai produttori di telefoni e chiunque voglia sviluppare software per Symbian ha la possibilità di scrivere e installare applicazioni, indipendentemente dai costruttori di dispositivi. Questo è in netto contrasto con i tradizionali sistemi operativi dei cellulari nei quali tipicamente il software è prodotto unicamente dalla casa produttrice, e non vengono accettati prodotti provenienti da terze parti. L idea di realizzare una piattaforma leggera e flessibile che potesse stare in un cellulare nasce nel 1998 dai leader dell industria della telefonia mobile Ericsson, Motorola, Nokia e dal 1999 Panasonic. Il punto di partenza fu la creazione di un sistema operativo, chiamato EPOC, sviluppato dalla Psion Software. Più tardi EPOC diventò Symbian OS e la Psion Software diventò Symbian. Il primo vero cellulare basato su Tecnologia Symbian era il modello di Ericsson R380 basato su Symbian Quartz versione 5.x, un sistema chiuso (cioè non programmabile al di fuori della casa madre). Attualmente la piattaforma Symbian vanta una serie di terminali sempre più vasta, per citarne solo alcuni si va dagli ultimissimi Nokia (N70, N71, N80, N91, N92) al Samsung SGH-D720, al Sony Ericsson P990, ma comprende dispositivi di molte altre case: BenQ, Motorola, Sendo, Jujitsu, Panasonic, Foma, Siemens, Arima, Lenovo. Nella prima metà del 2005 i telefoni Symbian nel mondo sono arrivati a 39 milioni. Symbian OS è quindi un sistema operativo ad-hoc per smartphone, cioè per quei telefoni intelligenti che si differenziano notevolmente da quelli tradizionali in quanto sono terminali con elevate caratteristiche tecnologiche a metà strada fra PDA e cellulare, funzionalità di gestione di dati personali e di telefono, e soprattutto, hanno la possibilità di un altro con priorità inferiore. I thread sono infatti schedulati in base alla loro priorità, o mediante un round-robin se hanno la medesima priorità. 4 Gli application engine verranno illustrati nel paragrafo

33 3 Piattaforma di Sviluppo essere programmati. Questo si vede nell impressionante insieme di caratteristiche tecniche fornite dalle ultime versioni di Symbian che, mediante una particolare gestione della memoria e di un sistema multiprocesso, permette operazioni sicure e soprattutto efficienti considerando che le risorse di un cellulare sono ridotte sia in termini di batteria e di potenza, che in termini di memoria Symbian C++ Symbian OS è stato sviluppato usando il linguaggio C++, che è perciò il linguaggio nativo di programmazione in quanto fornisce pieno accesso alla piattaforma e alle funzionalità del dispositivo di basso livello. Utilizzando tale linguaggio gli sviluppatori possono accedere non solo agli application engine, ma anche ad una moltitudine di tecnologie quali Bluetooth, infrarosso, telefonia, funzionalità multimediali e così via. Le applicazioni possono anche essere sviluppate utilizzando Java MIDP 2.0 o Python, ma è il C++ che permette allo sviluppatore di ottenere il massimo potenziale della piattaforma in quanto a performance, e consente di produrre un ampia gamma di applicazioni che vanno dalla manipolazione della fotocamera, all invio di MMS o all accesso delle funzionalità di telefonia. Il linguaggio C++ utilizzato dal sistema operativo Symbian non è esattamente lo stesso usato in altri ambienti, in quanto è stato ottimizzato per dispositivi relativamente piccoli e con vincoli di memoria. La Standard Template Library (STL) infatti non è supportata, ed altre modifiche sono state applicate al C++ standard in quanto quest ultimo implementa caratteristiche non richieste da Symbian (come l ereditarietà privata) o, viceversa, non fornisce strumenti che questi richiede. Inoltre certi meccanismi del C++ standard, primo fra tutti la cattura di eccezioni mediante l uso di try-catch, non era disponibile nei primi compilatori, e risulterebbe comunque troppo pesante in termini di computazione per un dispositivo cellulare. Questo approccio generico di gestione degli errori è stato quindi sostituito da altri meccanismi ad-hoc più efficienti in termini di memoria, oltre che di CPU che verranno illustrati nel paragrafo La versione nativa della Symbian Ltd. di C++ utilizza la maggior parte dei costrutti 23

34 3 Piattaforma di Sviluppo del linguaggio standard, è ad oggetti e permette quindi di sviluppare software basato su componenti e su una architettura modulare, ma ha una sua nomenclatura e caratteristiche ad-hoc Architettura del Sistema Operativo Come si è gia affermato in precedenza, Symbian è nato per funzionare su dispositivi cellulari che, in quanto tali, sono caratterizzati da un basso consumo di potenza e da ridotte capacità di memoria. Questo fatto ha notevolmente influito sui disegni di progetto e sull architettura di questa piattaforma. Risorse hardware CPU - Symbian OS è progettato per CPU a 32 bit e gira esclusivamente su processori ARM (Advanced Risk Machines), il processore RISC a 32 bit ampiamente usato in svariati dispositivi embedded e, grazie alle caratteristiche di risparmio della potenza, dominante nei dispositivi mobili. Tale CPU è però decisamente più lenta se confrontata con quella di un normale PC. ROM - La ROM contiene il sistema operativo e le applicazioni, diversamente da quella di un PC che contiene solo il boot loader a la BIOS, mentre il resto è posto nell hard disk. La ROM è mappata nel drive z: e i programmi vengono eseguiti in ROM, invece di essere caricati in RAM ed eseguiti come su un PC. RAM - La RAM di sistema è usata per i programmi attivi e per il kernel, ed è usata come un disco accessibile dal drive c:. Poiché la RAM totale su un dispositivo tipico si aggira sui 16 MB, c è la possibilità di avere errori di disco pieno o di out-of-memory, anche se con il diminuire dei prezzi si ha un maggiore utilizzo di memorie Flash (che hanno il vantaggio aggiuntivo di non richiedere una costante alimentazione per conservare i dati). 24

35 3 Piattaforma di Sviluppo Dispositivi di I/O - Comprendono lo schermo, il tastierino (che può essere più o meno compatto), memory-card slot, porte seriali, porte infrarosso e Bluetooth. Batteria - La gestione della potenza è critica in quanto ci si aspetta che un dispositivo cellulare funzioni per parecchie ore, se non giorni, tra una ricarica e l altra. Viste queste premesse si può ribadire che Symbian è un sistema operativo ad-hoc per cellulari, e che anzi il suo punto di forza sta proprio nell essere pensato per dispositivi con forti vincoli di risorse e che possono funzionare per mesi o anni senza essere spenti e senza perdere i dati dell utente. Questa forte enfasi di conservazione della memoria viene realizzata nei fatti mediante una programmazione specifica fatta di costrutti quali descrittori e cleanup stack, che insieme ad altre tecniche, permettono di mantenere basso l utilizzo della memoria e di ridurre considerevolmente la frequenza dei cosiddetti memory leak 5. Si hanno tecniche simili anche per una migliore conservazione dello spazio su disco, poiché non si hanno hard disk (a parte recentemente memorie flash) e non si può certo assumere di avere spazio infinito per immagazzinare programmi e dati utente. Inoltre tutta la programmazione Symbian è basata ad eventi, in modo che la CPU non sia in esecuzione ogni qual volta un applicazione non sta direttamente interagendo con un evento. Questo è realizzato grazie ad un costrutto di programmazione denominato active object (vedi paragrafo 3.4.6). Il corretto uso di queste tecniche, che verranno dettagliate ulteriormente in seguito, permette di assicurare un tempo di vita della batteria più lungo. Struttura Symbian nasce come un sistema operativo completo in termini di funzionalità. Riassumendo le sue principali caratteristiche sono: 5 Un memory leak è un consumo di memoria da parte di un programma, dovuto al mancato rilascio di risorse quando esse non sono più utili. 25

36 3 Piattaforma di Sviluppo 1. Performance : Symbian OS è progettato per massimizzare la durata della batteria attraverso un accurata gestione di potenza 2. Ambiente aperto : Symbian OS permette al telefono cellulare di essere una piattaforma aperta per installare applicazioni e servizi sviluppati in diverse lingue e formati di contenuto 3. Interoperabilità : mediante un implementazione flessibile e modulare, Symbian fornisce un set di base di API (Application Programming Interfaces) e tecnologie condivise da tutti i telefoni basati su tale sistema operativo. Inoltre l utilizzo di tecnologie basate sugli standard principali (Open Standards) consente di rendere le applicazioni interoperabili con soluzioni di altri produttori 4. Multi-tasking : è fondamentale perché componenti essenziali come telefonia, messaggistica e comunicazioni sono progettati per funzionare in parallelo. Le API Symbian C++ consentono alla gestione della memoria e al multi-tasking di essere estremamente efficienti, facendo in modo che operazioni pesanti in termini di memoria come i context switching 6 vengano minimizzate. Questo perché le applicazioni principalmente si basano su eventi invece di sfruttare il multithread, che è possibile e di norma usato dal sistema operativo, ma generalmente evitato dalle applicazioni, in quanto potenzialmente crea parecchi kilobyte di overhead per thread. Viceversa un approccio basato ad eventi non ha bisogno di context swhitching e può avere un overhead dell ordine di poche decine di byte 5. Interfaccia utente flessibile : usando un interfaccia grafica flessibile e lo stesso sistema operativo di base si facilita la portabilità di applicazioni per gli sviluppatori 6. Robustezza : Symbian OS assicura integrità dei dati anche in casi di carenza di memoria, spazio e batteria, o in presenza di comunicazioni non affidabili. 6 Il context switch è quella parte del kernel del sistema operativo che cambia il processo correntemente in esecuzione su una delle CPU permettendo a più processi di condividere una stessa CPU, ed è utile quindi nei sistemi con un solo processore, perché consente di eseguire più programmi contemporaneamente. 26

37 3 Piattaforma di Sviluppo Il cuore del sistema operativo Symbian consiste in una parte di base che comprende il microkernel e i driver dei dispositivi, un middleware composto dai server di sistema e dal framework applicativo e una parte per le comunicazioni come telefonia e Personal Area Network. Questo nucleo del sistema operativo è comune a differenti dispositivi che supportano Symbian OS, e naturalmente se il sistema operativo venisse adattato ad un altro hardware, la parte di base necessiterebbe di essere modificata (mediante il processo noto come base porting), ma questo non intaccherebbe i livelli superiori. D altro canto se due cellulari avessero librerie per l interfaccia utente che forniscono look and feel completamente diversi, avrebbero comunque ancora in comune la base sottostante costituita dal sistema operativo e questo permette l interoperabilità, semplifica lo sviluppo di applicazioni per diversi dispositivi e ne diminuisce il costo. La generica struttura del sistema operativo Symbian versione 8.0a è riportata nella figura 3.2. Analizzando tale struttura si vede che ai livelli più bassi, localizzati nel livello base del sistema operativo si hanno il kernel, il file server, la libreria utente e i driver dei dispositivi. Figura 3.2. Architettura di Symbian v8.0a OS 27

38 3 Piattaforma di Sviluppo Il kernel di Symbian ha un architettura a microkernel, il che significa che al suo interno vi è solamente il minimo necessario. Esso contiene uno scheduler e un gestore della memoria, ma nessun supporto per il networking o per il file system, che sono forniti dai server lato utente. Il kernel è eseguito direttamente nel processore in modalità privilegiata per poter avere accesso e gestire le risorse hardware come memoria e potenza, ed è responsabile del time-slicing per quanto riguarda le applicazioni e i task di sistema. Il controllo delle periferiche è quindi materia esclusiva del kernel in quanto la CPU svolge determinate istruzioni privilegiate solamente per esso, mentre i programmi in modalità utente non hanno privilegi per accedere direttamente alle risorse, se non usando le API esportate dal kernel. I driver dei dispositivi forniscono il controllo e l interfaccia a specifiche periferiche come la tastiera, il display o le porte seriali. Rappresentano il livello di interfaccia hardware-software necessario per accedere alle risorse. La libreria utente invece consente di usare molte delle funzionalità come gestione errori, livello di astrazione dell hardware e architettura client-server, oltre che permettere alle applicazioni lato utente di fare richieste al kernel. Il file server fornisce una visione del file system sul dispositivo per cui ogni drive ha una lettera, e i backslash vengono usati per delimitare i direttori. Vari file system sono supportati tra cui FAT32 e NOR, e generalmente non sono esposti all utente attraverso l interfaccia grafica. Nei livelli superiori vi è una consistente parte dedicata al networking e ai sistemi di comunicazione (TCP/IP, IMAP4, SMS e gestione database), che è sostanzialmente costituita da tre server principali: ETEL (EPOC telephony), ESOCK (EPOC sockets) and C32 (responsabile per comunicazioni seriali). Vi è inoltre una parte per comunicazioni di basso raggio come Bluetooth, IrDA e USB. Quel che offre l architettura di comunicazione è l infrastruttura e le pile protocollari dei più comuni standard. Il framework applicativo è costituito da un set di librerie che forniscono i mezzi per gestione testo, grafica e suono. Parte del framework è anche costituito dal window server (provvede all accesso e utilizzo di tastiera) e dal framework grafico. 28

39 3 Piattaforma di Sviluppo Particolarmente importanti nell architettura Symbian sono i server e l architettura Client/Server. Un server è un programma senza interfaccia grafica, eseguito in un processo separato, che gestisce una o più risorse. I client di tali server possono essere applicativi utente, altri server o processi di sistema. I server di sistema hanno un alta priorità, ma non possiedono privilegi di sistema, e possono essere usati solo attraverso particolari interfacce. Vi è infine una suite di application engine per applicazioni tipiche degli smartphone come calendario, rubrica telefonica, registro, agenda e servizi multimediali Serie 60 La Serie 60 o S60 è la piattaforma per telefoni mobili che si appoggia sul sistema operativo Symbian. È attualmente tra le piattaforme dominanti sul mercato, ed è stata sviluppata da Nokia e concessa in licenza ad altri produttori quali Panasonic, Samsung, Sendo, Siemens, Lenovo, LG Electronics, Panasonic e Samsung. L interfaccia grafica della Serie 60 è progettata per operazioni che possono essere svolte con una mano e che permettono quindi di avere una tastiera ridotta, diversamente da quella della Serie 80. Possiede uno schermo a colori con dimensione di 176 x 208 pixel, e la tastiera presenta dodici tasti numerici e tasti dedicati a particolari funzioni, come i cosiddetti softkeys (per la scelta delle opzioni presentate a video) e un tastierino con quattro direzioni. Un importante caratteristica della Serie 60, del resto comune al sottostante sistema operativo, è quella di permettere l installazione di applicazioni dopo l acquisto del cellulare, ed è per questo che viene fornito agli sviluppatori un insieme di componenti e API usate dalle applicazioni che sono parte della piattaforma, ma utilizzabili anche da sviluppatori e terze parti. Tra le applicazioni offerte dalla Serie 60 si hanno avanzate applicazioni per telefonia, per la rubrica, calendario e album delle foto, sincronizzazione (SyncML), messaggistica, browsing, ed un applicazione per installare o rimuovere altre applicazioni dalla piattaforma. 29

40 3 Piattaforma di Sviluppo La Serie 60 è la base di cellulari come Nokia 7650, Nokia 3650, Nokia 6630 e Nokia N-Gage. Storia Quando nacque Symbian ogni fondatore ebbe la propria idea in merito alla creazione di una nuova era di terminali mobili. In particolare la principale differenza tra le parti in gioco stava nell interazione con l utente e, per superare queste divergenze, venne introdotto il concetto di progetto di riferimento. I tre progetti originali erano Crystal, Quartz, e Pearl. Crystal e Quartz sono dispositivi di tipo communicator, Crystal con display orizzontale a 640 x 200 pixel e Quartz con display ad orientamento verticale a 240 x 320 pixel e touch screen. Pearl è il progetto di riferimento di cui la piattaforma Serie 60 è l esempio più significativo. Con l introduzione di Symbian OS v7.0, Quartz è stato rinominato UIQ ed è distribuito nelle versioni stretta (208 x 320) e normale (240 x 320) dalla UIQ Technology. Crystal è ora chiamata Serie 80 dalla Nokia. L attuale set di stili per l interfaccia utente è presentata in figura 3.3. Figura 3.3. Symbian OS: La Serie 60, UIQ e la Serie 80 Poiché il display è una delle parti più costose di uno smartphone, la Serie 60 risulta 30

41 3 Piattaforma di Sviluppo essere alquanto appetibile ai costruttori di terminali per la sua risoluzione dello schermo da 176 x 208 pixel. UIQ fornisce un display leggermente più largo, con operazioni eseguibili con penna; la Serie 80 ha la più grande dimensione dello schermo. Ogni stile dell interfaccia permette la personalizzazione del look and feel in termini di dimensione, forma, colore della grafica, cambio dei menu e aggiunta di nuovi componenti, in modo da adattarsi meglio al dispositivo in questione. Edizioni della Serie 60 Le edizioni della Serie 60 ne rappresentano i passi di evoluzione caratterizzati dalle varie modifiche e caratteristiche aggiuntive rispetto alle versioni precedenti. Tipicamente un edizione è anche accompagnata da aggiunte e cambiamenti del sottostante sistema operativo. Il vantaggio di questo procedere sta chiaramente nella possibilità di aggiungere progressivamente nuove funzioni e potenzialità, ma allo stesso tempo nel mantenere una certa continuità di compatibilità e interoperabilità dei software. Infatti chi sviluppa applicazioni per un dispositivo cellulare si trova di fronte al compromesso tra i costi di portabilità del prodotto ad un nuovo dispositivo e il mantenimento di una più larga fetta di acquirenti. La Serie 60 permette di ottenere il massimo da questi due aspetti perché fornisce l implementazione software per tutti i dispositivi basati su una particolare edizione della piattaforma. Gli sviluppatori possono essere sicuri che le applicazioni create usando le caratteristiche di un edizione potranno essere facilmente trasferiti verso qualsiasi dispositivo basato su quell edizione. Oltre le edizioni vi sono i Feature Pack, cioè distribuzioni di caratteristiche aggiuntive rese disponibili tra l uscita di un edizione e l altra. Ad esempio la seconda edizione presenta tre Feature Pack, ognuno dei quali porta una crescita nelle capacità della versione della piattaforma. Questo permette a quest ultima di evolvere continuamente, mantenendo una comune linea guida e coerenza attraverso le edizioni. Le successive distribuzioni della Serie 60 e le rispettive versioni di Symbian OS su cui si appoggiano sono: 31

42 3 Piattaforma di Sviluppo S60 1 Edizione - Symbian OS v6.1. S60 2 Edizione - Symbian OS v7.0s. S60 2 Edizione, Feature Pack 1 - Symbian OS v7.0s. S60 2 Edizione, Feature Pack 2 - Symbian OS v8.0a. S60 2 Edizione, Feature Pack 3 - Symbian OS v8.1a. S60 3 Edizione - Symbian OS v9.1. S60 3 Edizione, Feature Pack 1 - Symbian OS v9.2. Com è già stato ricordato in precedenza, l edizione della Serie 60 utilizzata nel lavoro di tesi è stata la S60 2 Edizione Feature Pack 2, cioè quella che utilizza il sistema operativo Symbian OS v8.0a, e quindi la trattazione si limiterà a esporre solamente le caratteristiche tecniche e funzionalità di questa distribuzione nei successivi sottocapitoli. Symbian OS v8.0a Anche la versione 8.0a di Symbian è un sistema operativo ottimizzato per terminali mobili ed è il sistema di base sotto il quale la Serie 60 2 edizione Feature Pack 2 è stata costruita. Tale piattaforma è un affidabile ambiente progettato in modo che i dati utente non vengano mai persi e in modo che il sistema non abbia mai bisogno di essere riavviato. Come già visto in precedenza Symbian ha un approccio totalmente ad oggetti: tutti gli oggetti di sistema, dalle applicazioni ai gestori di interrupt, sono definiti e trattati come classi C++. Questo indubbiamente contribuisce in modo positivo alla flessibilità, efficienza e riusabilità dei segmenti di codice. Inoltre un set di API consente alla comunità di sviluppatori, inclusi i produttori di telefoni cellulari, di creare applicazioni che possono essere facilmente scaricate, installate ed eseguite nativamente su terminali Symbian. È così possibile realizzare in modo efficiente il multitasking, la gestione della memoria poiché operazioni pesanti come context switching sono minimizzate. 32

43 3 Piattaforma di Sviluppo Symbian OS esporta altresì librerie che consentono l utilizzo e lo sviluppo per un vasto insieme di tecnologie che includono, tra le altre, Bluetooth, grafica, infrarosso, multimedia, messaggistica, networking e ovviamente telefonia. I principali miglioramenti di Symbian v8.0a sono elencati di seguito: 1. KERNEL REAL-TIME - è stato introdotto il supporto per due differenti kernel, uno dei quali è real-time (chiamato EKA2). Il motivo principale per avere introdotto una versione real-time del kernel è assicurare che un certo numero di API critiche sia del kernel, che lato utente, operassero con garanzie real-time. In questo modo il kernel è robusto e efficiente in termini di potenza. 2. SICUREZZA - si ha totale crittografia, gestione dei certificati, protocolli sicuri come HTTPS, SSL e TLS, e installazione delle applicazioni basata su certificati. 3. MULTIMEDIA - astrazione hardware per audio, video, MIDI che permette un più semplice sviluppo di applicazioni multimediali. Fotocamera da 1.3 megapixel con zoom 6x. 4. GRAFICA - accesso diretto allo schermo e alla tastiera per un controllo più performante. Si sono inoltre introdotte API per accelerazione grafica. 5. COMUNICAZIONI TRA PROCESSI - un framework più flessibile per messaggi asincroni tra thread e processi; uno di questi è un buffer condiviso di I/O che permette ai driver dei dispositivi di condividere dati in modo diretto e sicuro senza la necessita di copiare i dati. 6. JAVA - Java 2 Platform, Micro Edition (J2ME), Mobile Information Device Profile (MIDP) 2.0 e migliorie alle capacità di MIDP 2.0. Inoltre sono state incluse le API Java Mobile 3D Graphics API for J2ME (JSR-184), FileConnection API (JSR- 75), e PIM API (JSR-75) e il supporto per i più recenti standard wireless inclusi CLDC 1.1, JTWI (JSR185), Mobile Media API (JSR135), Java API for Bluetooth (JSR082) and Wireless Messaging (JSR120). 33

44 3 Piattaforma di Sviluppo 7. GESTIONE DISPOSITIVO - aggiunto supporto per la gestione remota del terminale che può essere effettuato attraverso qualsiasi tra i protocolli di sessione HTTP, WSP, OBEX. 8. MESSAGGI - messaggi multimediali (MMS), messaggi avanzati (EMS) e SMS; gestione mail usando i protocolli POP3, IMAP4, SMTP e MHTML. 9. PROTOCOLLI DI COMUNICAZIONE - stack protocollari come TCP/IP (sia IPv4 che IPv6) e WAP, supporto per personal area network inclusi infrarosso (IrDA), Bluetooth e USB. Qualità di servizio per reti GPRS e UMTS. 3.4 Programmare con Symbian Il processo di creazione applicazioni per Symbian è piuttosto lungo e laborioso e l utilizzo dell emulatore non sempre può aiutare lo sviluppatore. Infatti tale strumento può essere essenziale e notevolmente utile nel caso, per esempio, di implementazione di interfacce grafiche, ma di scarso utilizzo se l obiettivo è l utilizzo di componenti hardware come microfono o interfacce di rete. Per tale ragione questa sezione presenta in modo sintetico i passi fondamentali per la compilazione e il deploy 7 per la piattaforma Serie 60 su un dispositivo reale, piuttosto che per l emulatore, oltre che fornire una descrizione dei principali file di progetto. Infine si analizzerà la struttura base di una qualsiasi applicazione Symbian, studiandone le classi principali e le relazioni che intercorrono tra esse e con il framework, nonché una visione generale delle principali caratteristiche tecniche e implementative di Symbian Processo di sviluppo Il processo di sviluppo si dipana attraverso una serie di passi che portano all utilizzo funzionale dell applicazione sul terminale mobile. Essi sono: 7 Termine inglese usato per indicare il processo di caricamento dell applicazione compilata sul dispositivo finale. 34

45 3 Piattaforma di Sviluppo 1. Scelta del Software Development Kit (SDK) 2. Definizione dei componenti di progetto 3. Compilazione per cellulare 4. Deploy Scelta del Software Development Kit Vi sono numerose e diverse versioni di SDK disponibili, ognuna costruita su specifiche distribuzioni di Symbian e quindi per specifici prodotti della Serie 60. Una SDK contiene un buon numero di strumenti, API, librerie e documentazione per lo sviluppo di nuove applicazioni. È necessario scegliere la corretta versione del SDK per il particolare prodotto scelto. Nokia rilascia SDK adatte allo sviluppo di specifiche versioni della piattaforma Serie 60. Questo significa che ogni prodotto della Serie 60 è basato su una certa distribuzione della piattaforma, e le SDK sono progettate e per essere appropriate allo sviluppo di quella particolare versione. Una particolare SDK può altresì essere adatta per versioni precedenti della piattaforma, ma questa backward compatibility 8 non è in linea di massima una regola generale e dipende dalla versione del sistema operativo Symbian usato alla base della piattaforma, dalle API usate dal programmatore e dalle modifiche che queste API hanno subito tra una versione e la successiva. Definizione dei componenti di progetto Symbian dispone di un metodo per specificare i progetti in modo indipendente rispetto alla piattaforma e rispetto al compilatore. Tale metodologia consiste nella creazione di file di progetto universali chiamati nomeprogetto.mmp e bld.inf, in cui nomeprogetto è il nome del componente o applicazione da sviluppare. Questi due 8 Letteralmente compatibilità all indietro, cioè la possibilità di utilizzare vecchie applicazioni su nuove piattaforme. 35

46 3 Piattaforma di Sviluppo file di testo possono poi essere usati come punto di partenza per qualsiasi opzione di compilazione, IDE (Integrated Development Environment) e variante di piattaforma. Il file bld.inf specifica il nome di tutti i componenti del progetto che devono essere compilati e cioè contiene il nome del file mmp, il quale contiene a sua volta le specifiche del progetto. Entrambi i file sono in formato di puro testo, e spesso nel bld.inf si ha semplicemente il nome del file mmp che definisce l applicazione che si sta creando. Se il progetto consiste di componenti multipli, come possono essere specifiche librerie, allora ogni componente possiede il suo file di specifica mmp, ognuno dei quali è elencato nel file bld.inf del progetto. Tipicamente viene impiegato lo strumento della SDK Symbian bldmake che prende come input questi due file e genera un file di comando chiamato abld.bat. Quest ultimo può essere usato dal prompt dei comandi per eseguire un certo numero di operazioni relative al progetto, come la generazione del makefile specifico per la piattaforma e per l IDE. Inoltre, se sono disponibili i codici sorgenti del progetto, il comando abld permette di compilare l applicazione per una o più piattaforme. Il file mmp ha la seguente struttura TARGET BlueVoice.app TARGETTYPE app UID 0x100039CE 0x101FF1C6 TARGETPATH \system\apps\bluevoice SOURCEPATH..\src SOURCE BlueVoiceApp.cpp RESOURCE..\data\BlueVoice.rss LANG SC USERINCLUDE. SYSTEMINCLUDE. \epoc32\include LIBRARY euser.lib AIF BlueVoice.aif path resource [color-depth] source-bitmap-list Il campo TARGET specifica il file generato dal progetto. Sono necessari solamente 36

47 3 Piattaforma di Sviluppo il nome del file e l estensione perché il percorso dipende dalla piattaforma usata. Il TARGETTYPE conferma quanto indicato nel campo precedente, specificando se il progetto è un programma eseguibile (exe), un applicazione grafica (app), una libreria dinamica (dll) o un device driver fisico (pdd). L UID rappresenta l identificatore unico del progetto. I file binari prodotti in output vengono posti nel percorso indicato da TARGETPATH. Il percorso dove trovare i sorgenti sono invece posti nella cartella SOURCEPATH, mentre i singoli file sono specificati dal campo SOURCE che può essere usato più volte. I campi USERINCLUDE e SYSTEMINCLUDE specificano le directory dove ricercare i file di inclusione rispettivamente dell utente e di sistema. Tutti i progetti Symbian debbono specificare \epoc32\include\ nel percorso indicato da SYSTEMINCLUDE. Il campo LANG permette di specificare il linguaggio usato per generare i file per le risorse per ogni lingua indicata. Le risorse usate dal progetto sono indicate nei file definiti dal campo RESOURCE. I file risorsa definiscono appunto tutte le risorse di un applicazione, come stringhe, menu, finestre e altri elementi del display personalizzabili. Esse sono gestite al di fuori del codice sorgente dell applicazione per rendere la localizzazione, e quindi la traduzione in lingue diverse, più semplice. Ogni linea che inizia con LIBRARY indica una specifica libreria.lib a cui collegarsi. AIF definisce l Application Information File, ovvero il file contenente l icona bitmap e relativa didascalia dell applicazione. 37

48 3 Piattaforma di Sviluppo Poiché la maggior parte dei progetti vengono sviluppati nell ambito di un IDE, è conveniente creare file adatti per tale ambiente, in modo da permettere lo sviluppo, la compilazione e il debug dell applicazione con il totale supporto dell IDE, ma è possibile svolgere tali operazioni anche da linea di comando. La figura 3.4 illustra l uso dei due generici file di progetto per Symbian OS per la generazione degli altri file dipendenti dalla piattaforma, sia mediante l uso di un IDE che con il semplice uso del comando dal prompt. Figura 3.4. Generazione dei file di progetto specifici mediante file generici Symbian 38

49 3 Piattaforma di Sviluppo Compilazione per cellulare La compilazione per un dispositivo della Serie 60 mediante Visual C++ deve essere effettuata da linea di comando usando il file abld.bat, mentre IDE come CodeWarrior permettono tale operazione all interno dell ambiente di sviluppo. Nel caso di dispositivi Symbian l hardware che esegue l applicazione è un processore ARM ed è perciò necessario un compilatore per PC adatto 9 per ottenere gli eseguibili in un formato binario appropriato al processore ARM. Il metodo più generale per eseguire questa operazione è da prompt dei comandi. È necessario accedere alla cartella group del progetto dove è contenuto il file bld.inf ed eseguire i seguenti comandi: 1. bldmake bldfiles per generare il file abld.bat 2. abld build armi urel per Visual C++ e CodeWarrior abld build armib urel per Borland C++ Questo farà si che abld invochi il comando di sistema build preposto alla crosscompilation 10 e al linking 11 per produrre i file richiesti per la creazione dell applicazione, inclusi i file delle risorse, e quindi per l esecuzione sul terminale mobile. Vi sono tre tipi diversi di binari eseguibili, o Application Binary Interfaces (ABI) che possono essere generati per dispositivi basati sul processore ARM: ARMI, ARM4 e Thumb. ARM4 ha un lieve vantaggio di performance rispetto ad ARMI al costo di una maggiore dimensione del binario, ma tuttavia non è interoperabile con Thumb che è il minore in termini di dimensioni del codice poiché usa istruzioni su 16 bit piuttosto che su 32 bit. L unico binario che è interoperabile con le altre due varianti è ARMI 9 Come il compilatore GNU gcc C++ fornito dalla SDK della Serie Un cross-compilatore è un compilatore in grado di produrre codice eseguibile per una piattaforma diversa da quella su su cui tale compilatore viene eseguito. È un valido strumento se si vuole compilare per una piattaforma a cui non si ha accesso, o perché è sconveniente la compilazione in tale ambito come nel caso di sistemi embedded. 11 Il linking è il processo di integrazione dei vari moduli (da intendersi come sottoprogrammi o librerie) referenziati da un programma in una singola unità eseguibile. Il linker (o link editor) è un programma che prende uno o più oggetti generati dai compilatori e li assembla in un unico programma eseguibile. 39

50 3 Piattaforma di Sviluppo (ARM Interworking), ed è per questo che è conveniente adottare questa scelta in modo da garantire la compatibilità con il maggior numero di dispositivi fisici. I passi della compilazione comprendono inoltre la compilazione delle risorse e la creazione del file.aif. Il trasferimento dei file può avvenire copiando questi ultimi sulla memory card, ma tipicamente questo passo è preceduto dall impacchettamento di tutti i componenti applicativi in un particolare file di installazione. Nella sezione successiva è sintetizzata questa procedura. Deploy Il deploy consiste nel riunire i vari componenti di un applicazione per trasferirli nel dispositivo della Serie 60 e mandarli in esecuzione. Le applicazioni vengono inviate sotto forma di un file.sis ovvero Symbian Installation System, cioè un singolo file di archivio compresso contenente tutti i file necessari per l installazione, più qualche informazione opzionale per il processo di installazione. Il file.sis fornisce una semplice e consistente interfaccia utente per poter installare applicazioni, dati o informazioni di configurazione su dispositivi basati sul sistema operativo Symbian. Per produrre un file di installazione la SDK della Serie 60 di Symbian fornisce uno strumento chiamato makesis.exe che prende come parametro di ingresso il file di package nomeprogetto.pkg ovvero il file definito in forma testuale e contenente informazioni sulla lingua, UID e versione dell applicazione, un identificativo per applicazioni della Serie 60, ed infine i file compilati necessari per eseguire l applicazione sul dispositivo. È quindi necessario accedere alla cartella contenente tale file (tipicamente denominata install o sis) ed eseguire il comando: makesis nomeprogetto.pkg Una volta creato con successo il file.sis è sufficiente trasferirlo sul dispositivo per 40

51 3 Piattaforma di Sviluppo poter usufruire dell applicazione. Si hanno potenzialmente tre opzioni per l invio, in base al dispositivo che si usa e ai servizi disponibili. L installazione può avvenire mediante una sessione Bluetooth o infrarossa tra il PC e il cellulare stabilita via software (per esempio Nokia PC Suite), o gestita dalle applicazioni di messaggistica che intercettano il file allegato al messaggio breve inviato. Infine il file.sis può essere inviato come allegato di una mail e l installazione è automaticamente iniziata all apertura del documento. Quel che rimane del file di installazione è una versione ridotta del.sis file, che rimane sul dispositivo per controllare un eventuale disinstallazione dell applicazione, mediante lo strumento Manager. Tale file contiene poche informazioni (solo quelle richieste per la rimozione) ed ha infatti dimensioni significativamente minori rispetto all originale Applicazioni Symbian Le applicazioni possono seguire diversi processi di modellizzazione nello sviluppo, dipendentemente da molti fattori, come per esempio le piattaforme di utilizzo e le caratteristiche del software. Di seguito verrà presentato oltre che il framework applicativo che gestisce il ciclo di vita di un applicazione, anche i suoi componenti di base, senza i quali non è possibile avere un prodotto Symbian. Il framework applicativo Il framework applicativo o application framework è costituito da un insieme di classi di base e rappresenta il cuore di tutte le applicazioni. Tali classi formano la struttura di ogni applicazione e incapsulano le interazioni tra esse e i server del sistema operativo, di cui è già stato trattato nel paragrafo La figura 3.5 mostra, mediante un diagramma UML, il raggruppamento concettuale delle classi dell application framework, le API contenute in questi gruppi e le relazioni di eredità. Il primo livello nella gerarchia delle classi è diviso in due componenti fondamentali denominati AppArc e CONE. AppArc significa Application Architecture, e fornisce la 41

52 3 Piattaforma di Sviluppo Figura 3.5. Framework applicativo struttura di base delle applicazioni, i meccanismi per inviare informazioni di sistema alle applicazioni e uso di dati persistenti mediante il File Server. Le classi appartenenti a tale categoria possiedono il prefisso Apa. CONE è l abbreviazione di CONtrol Environment, e le classi di questo componente possiedono i meccanismi per gestire l interfaccia utente, interagendo con il Window Server 12. Le classi di tale componente sono caratterizzate dal prefisso Coe. Il secondo livello di classi è rappresentato dal componente Symbian Uikon. Esso è un livello Symbian di interfaccia utente grafica che fornisce controlli generici e implementazioni indipendenti dall hardware per classi astratte e altamente funzionali. Fornisce inoltre le librerie UI che sono comuni a tutte le piattaforme del sistema operativo Symbian. In questo livello possono essere creati alcuni controlli concreti della UI come list 12 Il Window Server è un server Symbian che controlla gli input dell utente. 42

53 3 Piattaforma di Sviluppo box e scroll bar, riferiti sovente come controlli Eikon 13. Conviene comunque usare i controlli Avkon 14 perché garantiscono il corretto comportamento per le applicazioni Serie 60. Le classi in questo componente hanno il prefisso Eik. Il terzo livello consiste nell insieme di classi Avkon, le quali rappresentano le funzionalità per l interfaccia utente di base della Serie 60. Tale livello è un implementazione puramente per la Serie 60 e un applicazione per questa piattaforma dovrebbe sempre derivare da tali classi piuttosto che quelle generiche Symbian. Le classi Avkon hanno il prefisso Akn. L ultimo livello, quello specifico per le applicazioni, illustra come le classi di un applicazione dovrebbero derivare dalle classi Avkon. Tali classi e le loro funzionalità saranno dettagliate meglio nella sezione successiva. In definitiva si può riassumere che le classi del primo livello sono astratte e definiscono semplicemente l interfaccia alle API del framework; il secondo livello aggiunge un implementazione comune, condivisibile con altre piattaforme Symbian OS; il terzo fornisce una specifica implementazione al framework per la Serie 60 e il quarto rappresenta il livello di implementazione dello sviluppatore. Architettura applicativa La terminologia architettura applicativa si riferisce ad una insieme di classi dell application framework che collettivamente formano un applicazione. Le applicazioni possono avere sottili differenze architetturali basate sul progetto dell interfaccia grafica richiesto, ma in ultima analisi le classi preposte alla costituzione dell applicazione condividono alcune funzionalità di base: Permettono l interazione con l utente rispondendo ad eventi come la scelta di un opzione da un menu 13 EIKON consiste di un framework di programmazione e di un insieme di controlli concreti e finestre standard. EIKON è stato rimpiazzato in Symbian OS v6.0 da UIKON e da librerie specifiche per piattaforma. Queste librerie UI sono chiamate Avkon per la Serie Librerie standard specifiche per la Serie 60. Sono sviluppate sulla tecnologia Symbian Uikon. 43

54 3 Piattaforma di Sviluppo Rispondono a eventi di sistema come l aggiornamento dello schermo causato dal Windows Server Salvano e ripristinano dati applicativi Identificano unicamente l applicazione al framework e ne forniscono informazioni come icone e didascalia Il paradigma Modello-Vista-Controllo Sarebbe buona norma dividere le applicazioni tra la parte che presenta i dati all utente (l interfaccia grafica) e quella preposta alla manipolazione dei dati e alle operazioni non visibili all utente. Questa separazione può essere ottenuta mediante lo schema Modello-Vista-Controllo o MVC, tipico delle applicazioni S60. Il paradigma MVC divide l applicazione in tre moduli distinti: Modello : contiene e manipola i dati nel programma. Vista : definisce come i dati del Modello vengono presentati all utente, ed è quindi la vista attraverso la quale l utente vede il Modello. La Vista inoltra i comandi ricevuti e le richieste al modulo di Controllo. Controllo : definisce come l interfaccia utente reagisce alle richieste e ai comandi ricevuti. È quindi la parte del programma che aggiorna il Modello e che invia le richieste alla Vista per ridisegnare lo schermo in modo da mostrarne gli aggiornamenti. In questo modo la struttura MVC divide l applicazione in moduli logicamente disaccoppiati l uno dall altro. Un componente disaccoppiato può essere modificato o rimosso senza apportare modifiche agli altri componenti e questo va indubbiamente ad impattare in modo positivo sulla manutenibilità, flessibilità e portabilità del software. 44

55 3 Piattaforma di Sviluppo Classi di base dell applicazione Le applicazioni Serie 60 seguono il paradigma MVC poiché Symbian OS ne consiglia l uso. L anatomia di base di un applicazione consiste di un motore, a cui ci si riferisce col termine di engine, di un interfaccia grafica e di un componente per il modulo della Vista, in particolare si hanno le seguenti classi per fornire le funzionalità illustrate precedentemente: classe Application : il suo ruolo è statico e, oltre a servire da entry point 15 principale dell applicazione, invia al framework informazioni relative all applicazione come icone e didascalie rappresentative (e questo si vede nel menu di avvio di telefoni Symbian Serie 60) e serve per definire le proprietà dell applicativo. La classe Application non si occupa minimamente dei dati applicativi né degli algoritmi che li elaborano, ma possiede il compito di costruire un nuovo oggetto della classe Document (vedi punto seguente) e fornire funzioni che permettono di ottenere la didascalia della funzione, l accesso al suo file.ini e il suo identificatore unico (UID). Le classi di questa categoria derivano da CAknApplication classe Document : rappresenta il modello dei dati dell applicazione ed è tipicamente usata per caricare i dati in file, permettendo così all applicazione di essere persistente. Fornisce inoltre un metodo per costruire oggetti della classe AppUi ed è derivata da CAknDocument. classe AppUi : è la principale classe per l interfaccia utente dell applicazione. Essa crea e gestisce i controlli per visualizzare i dati, centralizza la gestione degli input da menu e toolbar ed è destinataria di numerose notifiche provenienti dal framework come la digitazione dei tasti da parte dell utente o di eventi di sistema. La classe AppUi tuttavia è totalmente invisibile, nel senso che delega le operazioni di visualizzazione (drawing) alla classe AppView che viene creata appunto per le interazioni con lo schermo. Le classi AppUi derivano da CAknAppUi. 15 È il punto d ingresso invocato dal sistema operativo subito dopo il caricamento. 45

56 3 Piattaforma di Sviluppo classe AppView : ha lo scopo di visualizzare i dati dell applicazione sullo schermo e permetterne l interazione. Tale classe eredita da CCoeControl. classe Engine : costituisce la componente Modello del paradigma MVC e non è rappresentato da una specifica classe Symbian Serie 60, ma incapsula i dati dell applicazione e i suoi algoritmi. L Engine appartiene alla classe Document (o a quella AppUi) che può usarne le funzionalità per caricare i dati. Le classi presentate possono essere collocate nel paradigma MVC come viene rappresentato nella figura 3.6 Figura 3.6. Archiutettura applicativa e MVC Convenzione dei nomi I programmatori Symbian utilizzano delle convenzioni per i nomi che hanno dei significati particolari in relazione alle funzionalità delle classi, all appartenenza degli oggetti e alle necessità di de-allocazione della memoria. Esse sono progettate per evitare errori di 46

57 3 Piattaforma di Sviluppo programmazione e facilitano lo sviluppo di applicazioni, ed è quindi buona norma attenersi a tali vincoli, anche per permettere la manutenibilità del codice ed il suo riutilizzo da parte di altri programmatori. Si hanno i tipi fondamentali definiti da un insieme di typedef, il cui uso è da preferirsi rispetto agli equivalenti tipi nativi di C++. Sono illustrati in tabella 3.1 Tabella 3.1. Tipi fondamentali in Symbian OS Tipi di Symbian OS Descrizione TBool (ETrue/EFalse) Valore Booleano su 32 bit TUint8 (TInt8) intero con segno (senza segno) su 8 bit TUint16 (TInt16) intero con segno (senza segno) su 16 bit TUint32, TUint intero senza segno su 32 bit TInt32, TInt intero con segno su 32 bit TUint64 (TInt64) intero con segno (senza segno) su 64 bit TReal64, TReal Rappresentazione in floating point su 64 bit TAny* Puntatore a un tipo non specificato Le classi devono invece avere un nome descrittivo dell oggetto e devono avere il prefisso C, T, R, o M in base alle seguenti regole Classi T : classi semplici che non possiedono nessun oggetto esterno o altre risorse, e che non richiedono perciò un distruttore esplicito. Sono molto simili a quelli che in C++ sono chiamati come tipi built-in, cioè quelle variabili definite dall utente con il comando typedef. Possono essere allocate sia sullo stack 16 che sullo heap 17. Classi C : classi derivanti da CBase e allocate sullo heap (non sullo stack). Dalla classe CBase ereditano il costruttore che inizializza a 0 l oggetto e il distruttore virtuale. Queste classi hanno la responsabilità di de-allocare altri oggetti, cioè possiedono puntatori ad oggetti costruiti sullo heap o gestori di risorse. 16 È adatto per oggetti dalla dimensione fissa il cui tempo di vita coincide con la funzione che li ha creati. Gli oggetti allocati sullo stack non debbono essere troppo grandi e possono essere brevi stringhe o puntatori. 17 Viene utilizzato per oggetti che sono costruiti o manipolati durante l esecuzione, o perché la loro dimensione è troppo grande per lo stack. 47

58 3 Piattaforma di Sviluppo Classi R : classi delle risorse che contengono dei gestori per una risorsa reale mantenuta da un server o all interno del kernel. Sono oggetti tipicamente istanziati sullo stack e la cui de-allocazione è gestita da un metodo Close. Classi M : dette anche classi Mixin, sono di fatto delle interfacce per descrivere definizioni astratte che vengono poi implementate dalle classi che derivano da esse. Rappresentano l unico modo concesso dal sistema Symbian per effettuare l ereditarietà multipla. Anche le funzioni hanno alcune regole sui nomi: I nomi delle funzioni iniziano con una lettera maiuscola Terminano con la lettera L se possono lanciare un eccezione Terminano con la lettera D se cancellano un oggetto Terminano con la lettera C se lasciano un oggetto sul cleanup stack Stringhe e descrittori In Symbian OS la gestione delle stringhe è effettuata mediante particolari classi denominate descrittori, che in parte differiscono dalle tradizionali stringhe di C++ terminate dal cosiddetto null-terminator. I descrittori hanno infatti questo nome perché sono auto-descrittivi, nel senso che tali oggetti incapsulano sia i dati veri e propri, sia informazioni come la loro lunghezza e la massima dimensione allocata. Questo significa che i descrittori possono prevenire le scritture dei dati in aree di memoria non allocate. In aggiunta, poiché non è necessario un terminatore della stringa, possono essere caricati in un descrittore anche dati puramente binari oltre che testuali, permettendo a queste classi di offrire una consistente interfaccia per gestire entrambi i tipi di dati. Questo è un chiaro esempio di come il codice in Symbian viene riutilizzato per diminuire la dimensione dei programmi. 48

59 3 Piattaforma di Sviluppo I descrittori sono manipolati grazie all utilizzo di un insieme di metodi forniti dalle due classi base TDesC (per funzionalità che non modificano i dati) e TDes (per funzionalità legate alla modifica dei dati). Come opzione predefinita i descrittori sono in formato Unicode, e quindi ogni carattere è su 16 bit, ma possono essere analogamente usati descrittori su 8 bit specificandone esplicitamente il tipo. I principali tipi di descrittori e le relative classi sono: Astratti (TDes, TDesC) : sono le classi base da cui ereditano gli altri descrittori. Esse non possono essere istanziate e vengono perciò usate nei parametri delle funzioni. Letterali (TLitC, _LIT()) : usati per memorizzare stringhe e testo. Buffer (TBuf, TBufC) : contengono dati memorizzati sullo stack e la dimensione è definita in fase di compilazione. Heap (HBufC) : contengono dati memorizzati sullo heap e la dimensione viene determinata in fase di esecuzione. Puntatori (TPtr, TPtrC) : sono riferimenti a dati contenuti al di fuori della classe Gestione delle eccezioni Fino alla versione 6 del sistema operativo Symbian il sistema di gestione delle eccezioni mediante try, catch() e throw non era supportata dalla piattaforma per ragioni storiche 18 e di efficienza 19. Per fornire un alternativa al controllo degli errori, Symbian usa un paradigma più leggero che funziona mediante le TRAP harness e le leave. Una cosiddetta leave è l equivalente in Symbian dell eccezione nel C++ tradizionale, ed è usata per propagare un errore all indietro sullo stack delle chiamate fin dove esso non venga catturato da una TRAP e gestito. Una TRAP harness non è altro che l equivalente del blocco catch del C++ ed è più leggera in termini computazionali in quanto 18 Quando furono rilasciate le prime versioni di Symbian l implementazione del meccanismo try-catch non era ancora stato standardizzato 19 La gestione ANSI C++ degli errori incrementa notevolmente le dimensioni del codice 49

60 3 Piattaforma di Sviluppo non viene lanciato un oggetto (come invece fa l invocazione della throw in C++), ma viene restituito un codice d errore su 32 bit alla macro TRAP o TRAPD preposte alla cattura. L esecuzione del codice termina effettivamente ad ogni leave lanciata e riprende all interno della TRAP. Viene lanciata un eccezione leave nei seguenti casi: chiamando il metodo statico User::Leave(). mediante la chiamata alla versione di Symbian dell operatore new che prende il parametro ELeave e lancia una leave se non c è sufficiente memoria per allocare l oggetto in fase di costruzione. in generale ogni qual volta una risorsa o della memoria non può essere allocata. Poiché la gestione delle eccezioni di Symbian OS non fa parte della sintassi di C++, non c è modo per il compilatore di controllare se un metodo che può lanciare una leave sia o meno all interno di una TRAP. La soluzione è quella già introdotta nella sezione sulla convenzione dei nomi per cui una funzione che può causare un eccezione possiede una L alla fine del nome. Inoltre, a meno che una funzione chiamante gestisce l eccezione con una TRAP, anch essa dovrà avere una L aggiunta al suo nome per indicare che indirettamente può lanciare una leave. In questo modo il programmatore che ha a che fare con una funzione terminante in L deve considerare i potenziali effetti sulla memoria allocata sullo heap se quel metodo dovesse fallire. Diversi invece sono i panic, cioè errori che non possono essere gestiti da una TRAP, ad esempio quando il programmatore eccede i limiti del descrittore. Non potendo essere catturato esso risulta nella terminazione del thread che ha lanciato il panic; se tale thread coincide col processo principale, anch esso verrà terminato. Le regole per creare oggetti sullo heap contengono fondamentalmente tre concetti: costruttori non pubblici, cleanup stack e costruzione in due fasi. Cleanup stack Quando una funzione lancia un eccezione tutte le variabili locali e i puntatori alle celle di memoria vengono persi. Per evitare questo, Symbian OS fornisce un cleanup stack 50

61 3 Piattaforma di Sviluppo nel quale lo sviluppatore carica i puntatori per tutto il tempo in cui vi è il rischio di un memory leak nel caso in cui la funzione dovesse fallire. Se ciò dovesse accadere i puntatori sono automaticamente estratti dal cleanup stack e le corrispondenti aree di memoria sono rilasciate. Normalmente tutte le risorse e le aree di memoria allocate sono liberate quando il thread che li ha istanziati muore, ma ovviamente non è consigliabile usare la memoria in questo modo poiché è possibile che certe applicazioni rimangano in esecuzione per mesi prima che il terminale mobile venga riavviato. Una situazione in cui si può verificare un memory leak è quella in cui si utilizzano variabili locali per mantenere i puntatori alle aree di memoria sullo heap. Se però la funzione in cui sono definite tali variabili dovesse lanciare una leave, essi verrebbero persi e non ci sarebbe modo per liberare e quindi riutilizzare quelle celle di memoria. La soluzione offerta da Symbian è quella di caricare tali puntatori nel cleanup stack, uno speciale stack per tenere traccia dei gestori delle risorse e dei puntatori di memoria. Automaticamente, in caso di fallimento della funzione, la memoria viene ripristinata senza dare adito a memory leak. Costruzione in due fasi Il bisogno della costruzione in due fasi sorge se un costruttore ha bisogno di allocare delle risorse o puntatori ad altri oggetti o comunque se deve svolgere operazioni potenzialmente pericolose in termini di allocazione della memoria e può quindi essere visto come uno sforzo per prevenire che la creazione di un oggetto lanci un eccezione. Il costruttore però non deve mai trovarsi in questa situazione poiché il distruttore non verrebbe chiamato in caso di mancata riuscita dell allocazione. La classe deve perciò esporre un metodo pubblico e statico NewL per la creazione dell oggetto. Lo sviluppatore non può usare il normale costruttore direttamente perché esso è dichiarato protetto (cioè può essere utilizzata solamente da oggetti che derivano da tale classe) o privato (non accessibile al di fuori della classe), mentre la funzione NewL si occupa di gestire l allocazione della memoria in modo da evitare memory leak. La classe NewL incapsula l uso del cleanup stack e segue i passi elencati: 51

62 3 Piattaforma di Sviluppo 1. L oggetto viene creato usando una versione overloaded 20 del operatore new che accetta come argomento ELeave il quale indica che la creazione dell oggetto fallisce se la memoria necessaria non può essere allocata. Questa è la prima fase della costruzione 2. Il puntatore all oggetto creato viene inserito nel cleanup stack. 3. La seconda fase della costruzione include la creazione degli oggetti posseduti dall oggetto appena creato. Secondo la regola delle due fasi questo viene implementato dell funzione chiamata ConstructL. 4. Al termine, quando si è in una situazione sicura (un eventuale leave non causerebbe la perdita dei puntatori), il puntatore dell oggetto viene estratto dal cleanup stack. Il codice relativo alla costruzione può essere ottimizzato mediante l uso della funzione, anch essa pubblica e statica, NewLC che chiama l operatore new con la costante ELeave, inserisce l istanza temporanea della classe nel cleanup stack e chiama il metodo ConstrucL lasciando l oggetto nello stack da cui verrà estratto dalla NewL Gestione degli eventi asincroni Per concludere questa parte dedicata al sistema operativo Symbian è doveroso menzionare, seppure brevemente, il meccanismo di gestione degli eventi asincroni mediante l uso degli Active Object. Innanzitutto bisogna tenere presente che i thread possono essere utilizzati per effettuare multi-tasking con preemption ma che il loro uso, sebbene frequente da parte del sistema operativo, è scoraggiato poiché è difficile da sviluppare, è inefficiente ed è pesante in quanto richiede context switching. Un altro meccanismo è quello che sfrutta gli active object e porta ad un multi-tasking cooperativo. Essi ereditano dalla classe CActive che fornisce funzioni virtuali e campi usati dal framework. È importante notare che gli active object vengono eseguiti all interno 20 L overloading è una caratteristica dei linguaggi ad oggetti per cui è permesso avere più funzioni con lo stesso nome, ma con parametri diversi e quindi funzionalità differenti 52

63 3 Piattaforma di Sviluppo di un thread, il che significa che la loro schedulazione non necessita di un cambio di thread o cambio di contesto (che ovviamente può succedere insieme alla schedulazione degli active object, per altri scopi) e che rende questa tecnica più leggera se comparata a quella dei thread. Gli active object implementano invece un multi-tasking senza preemption o senza diritto di prelazione 21 cioè una richiesta è eseguita completamente, una volta che il framework l ha iniziata. Gli active object hanno un loro schedulatore denominato Active Scheduler che deve essere installato all interno del thread, al quale deve essere aggiunto l eventuale active object e che infine deve essere attivato. Tipicamente un active object sfrutta un servizio asincrono fornito da un qualche server di cui possiede un handle, ovvero un oggetto per poterne gestire l uso e mediante il quale può avere accesso all interfaccia del server per potere rilasciare delle richieste asincrone. Caratterizzante lo stato della richiesta è il parametro istatus che, una volta istanziata la richiesta, assume il valore corrispondente alla costante KRequestPending. Per notificare all active scheduler che l oggetto è in attesa di completamento di una risorsa viene chiamato il metodo SetActive, in modo che l event loop implementato nello schedulatore venga attivato grazie alla chiamata alla funzione statica User::WaitForAnyRequest. In tal modo viene decrementato di uno il valore associato al semaforo del thread e, se il valore diventa negativo, il thread si mette in attesa di richieste completate dal server. Al termine del servizio, il server segnala il completamento della richiesta al thread e, nel caso in cui il valore del semaforo diventi nullo o positivo, lo schedulatore sceglie l active object che ha fatto la richiesta e che ha la priorità più alta e ne richiama la funzione RunL. Tale funzione è riscritta dallo sviluppatori a seconda delle esigenze e viene usata dallo schedulatore quando la richiesta è stata soddisfatta. Se l active object non ha intenzione di aspettare il completamento può chiamare la funzione Cancel la quale invoca la DoCancel opportunamente implementata dall utente, nella quale vengono rilasciate le risorse e chiusi i gestori dei server. 21 In questo caso lo scheduler deve attendere che il processo termini o che cambi il suo stato da quello di esecuzione a quello di attesa o di pronto, a seguito, ad esempio, di una richiesta di I/O oppure a causa di un segnale di interruzione (interrupt). 53

64 3.5 Scelte implementative 3 Piattaforma di Sviluppo Dall analisi che è stata effettuata in questo capitolo si può concludere che, allo stato attuale, J2ME è diventato uno strumento di sviluppo completo, che offre moltissime delle funzionalità messe a disposizione da Symbian OS. Inoltre risulta evidente uno dei vantaggi derivanti dalla scalabilità e dalla modularità di J2ME, e cioè la possibilità di implementare nuovi profili senza modificare le configurazioni di base esistenti con una conseguente riduzione dei tempi di sviluppo e dei costi di realizzazione. È anche da evidenziare che J2ME si è appoggiato a Symbian traendone miglioramenti in termini di performance e robustezza, e che Symbian trae invece vantaggio dal fatto che includere J2ME nel suo core rende il sistema operativo più vendibile. Non bisogna dimenticare infatti che, ad esempio, per i leader del mobile gaming conviene, per diffondere i propri prodotti, realizzarli utilizzando una tecnologia indipendente dal sistema operativo, e cioè Java. D altro canto C++ permette di avere le migliori performance in termini di lavoro svolto dalla CPU e facilita un più basso consumo di memoria e ovviamente di energia. Poiché Java vede tra gli obiettivi di progetto quello di poter essere compatibile su qualsiasi dispositivo, è intrinsecamente caratterizzato da lacune e compromessi nelle sue funzionalità generali. Un applicazione Java, ad esempio, non può avere controllo di tutte le caratteristiche di un telefono cellulare come la rubrica telefonica o il calendario. Poiché l applicazione di client VoIP richiede l utilizzo di hardware specifici come l auricolare e il microfono del telefono, necessita di utilizzi performanti delle capacità multimediali per poter fornire un servizio full-duplex 22, e ha bisogno di application engine particolari come ad esempio il registro delle chiamate per salvare le chiamate perse, lo studio di fattibilità effettuato ha fatto vertere la decisione verso la scelta di un applicazione realizzata in linguaggio C++ per Symbian, piuttosto di una basata su Java. Purtroppo questa decisione ha escluso in partenza la possibilità di usare un ambiente 22 Il full-duplex è una modalità di invio e ricezione di informazioni digitali, con funzione completamente bidirezionale e indica, in questo caso, la modalità di conversazione in un sistema di comunicazione, che è la modalità tipica di una conversazione telefonica tradizionale ovvero in cui i due utenti parlano e ascoltano contemporaneamente. 54

65 3 Piattaforma di Sviluppo di sviluppo potente e versatile come NetBeans che dispone, nelle ultime versioni, di strumenti avanzati per la produzione di software per terminali mobili, coadiuvato da un tool per facilitare l implementazione di interfacce grafiche. Per quanto riguarda il mondo di Symbian tra gli IDE principali vi è CodeWarrior che è però un software a pagamento. CodeWarrior è stato rimpiazzato nel 2006 da Carbide.c++, un IDE basato su Eclipse sviluppato dalla Nokia. Carbide.c++ è disponibile nelle versioni Express, Developer, Professional e OEM con crescenti livelli di capacità, come progettazione di interfacce grafiche e debug avanzato. Oltre a questi si aggiungono un plugin di Visual Basic per lo sviluppo di Symbian, di grande potenzialità ma anch esso a pagamento, e una versione dell IDE della Borland per Symbian OS. Poiché è possibile realizzare software in modo semplice vista la somiglianza ad Eclipse e in modo gratuito si è scelto come ambiente di sviluppo Carbide.c++ Express, di fatto meno performante di altre scelte, ma indubbiamente più immediato da utilizzare. Il pacchetto di sviluppo per applicazioni (SDK) scelto è stato invece quello relativa alla versione 8.0a di Symbian, cioè quella per il cellulare Nokia 6630, attualmente di largo utilizzo e disponibile al momento dell inizio del lavoro. 55

66 Capitolo 4 Tecnologie di comunicazione 4.1 Introduzione In questo capitolo verranno trattate le due tecnologie di comunicazione utilizzate per realizzare le funzionalità dell applicazione per cellulare sviluppata: Bluetooth e VoIP. Per quanto riguarda Bluetooth, se ne esaminerà il funzionamento e si darà una descrizione della pila protocollare, limitandosi in particolare modo agli aspetti usati e sviluppati nella realizzazione dell applicazione, al fine di evitare una trattazione troppo dettagliata di tale tecnologia che esula dagli intenti di questo lavoro 1. Si vedrà come i dispositivi si rendono visibili agli altri e si connettono tra di loro, quali tipi di connessione sono supportate e le librerie usate, sia per la programmazione lato server (API sviluppate in linguaggio C denominate BlueZ) che per quella lato client (API di sistema Symbian). Saranno perciò tralasciati particolari legati ai livelli hardware e caratteristiche di basso livello (come il formato dei pacchetti o le modulazioni usate), trasparenti a livello applicativo. Analogamente per VoIP verrà fornita una descrizione esaustiva di ciò che si intende per telefonia sulla rete Internet e, per quanto riguarda i protocolli che VoIP utilizza, ci si concentrerà prevalentemente su SIP in quanto ha giocato un ruolo determinante nella definizione del protocollo per la gestione della chiamata del software sviluppato e verrano 1 Per eventuali approfondimenti in materia si rimanda al sito ufficiale [10]. 56

67 4 Tecnologie di comunicazione quindi tralasciati gli altri protocolli. Inoltre verrà presentata una particolare implementazione di un applicazione per PC adatta ad iniziare, gestire e terminare una chiamata VoIP: SimpleOPAL. 4.2 Bluetooth Bluetooth è uno standard per comunicazioni radio wireless con corto raggio di copertura (da 10 a 100 metri), progettato per avere caratteristiche di bassi consumi e transceiver a basso costo. Nasce nel 1994 sviluppato da Ericsson per rimpiazzare il cablaggio, ed è oggi disponibile in moltissimi tipi di dispositivi come PDA, cellulari, PC, mouse e così via. Nel 1998 Ericsson ha unito i propri sforzi con Intel, IBM, Nokia e Toshiba per formare il Bluetooth Special Interest Group (SIG). Nel 1999 si sono aggiunte 3Com, Lucent/Agere e Microsoft, garantendo a Bluetooth di svilupparsi come standard aperto assicurandogli un accettazione rapida e piena compatibilità con il mercato. La prima versione dello standard è la 1.0 (Luglio 1999) che è uscita in tre varianti 1.0, 1.0a e 1.0b. In particolare le versioni 1.0 e 1.0b erano afflitte da molti problemi soprattutto nell interoperabilità fra dispositivi di diversi costruttori. La seconda versione è la 1.1 (Febbraio 2001) le cui differenze dalla versione precedente sono legate sostanzialmente alla correzione di alcuni problemi specifici evidenziatisi durante l uso, una ottimizzazione delle prestazioni, e la possibilità di comunicazione su canali non cifrati. Nel Giugno 2002, l IEEE ha prodotto una propria versione dello standard 1.1 denominata WPANs o IEEE , per indicare il primo task delllo standard che si occupa di sviluppare uno standard per Wireless Personal Area Network basato sulle specifiche Bluetooth. Nel novembre 2003 esce quindi la versione 1.2 che è retrocompatibile con la 1.1 a cui aggiunge miglioramenti per diminuire le interferenze in zone sovraffollate mediante selezione adattativa della sottobanda, per avere velocità di trasmissione più elevate e migliore qualità dei collegamenti voce grazie alla extended Synchronous Connections (esco) che in caso di perdita dei dati si ha ritrasmissione. Ma 57

68 4 Tecnologie di comunicazione il maggior miglioramento si ha con la versione 2.0 di Bluetooth che permette trasmissioni da 3 a 10 volte più veloci, copertura a 100 metri e un minor consumo energetico. Il protocollo Bluetooth lavora sulle frequenze libere di 2,45 Ghz. Per ridurre le interferenze il protocollo divide la banda in 79 canali e provvede a commutare tra i vari canali 1600 volte al secondo (meccanismo denominato Frequency hopping o FH). La versione 1.1 e 1.2 del Bluetooth gestisce velocità di trasferimento fino a 723,1 kbit/s. La versione 2.0 gestisce una modalità ad alta velocità che consente fino a 2,1 Mbit/s. Questa modalità però aumenta la potenza assorbita. La nuova versione utilizza segnali più brevi e quindi riesce a dimezzare la potenza richiesta rispetto al Bluetooth 1.2 (a parità di traffico inviato) Topologia della rete Due o più dispositivi Bluetooth che stabiliscono una connessione e condividono un canale radio, formano una piccola rete wireless ad-hoc denominata piconet che ha una capacità complessiva fino a 1 Mbit/s. In questa configurazione un terminale Bluetooth agisce come master, controllando il traffico della piconet, mentre tutti gli altri dispositivi si comportano da slave. Il master è definito come colui che iniziala procedura di connessione per stabilire la piconet, ed è unico all interno della rete. Il master stabilisce l accesso alla rete degli slave mediante un meccanismo a polling, cioè dando la possibilità di parlare agli altri nodi. All interno di una piconet possono essere attivi fino a 7 slave (8 se si considera anche il master), ma è possibile comunque avere fino a 255 ulteriori dispositivi che però devono essere nello stato inattivo parked, cioè non possono trasmettere, ma mantengono la sincronizzazione con il master e possono essere riattivati in qualunque momento dal master. Due piconet spazialmente sovrapposte possono essere collegate tra loro tramite un dispositivo Bluetooth (gateway o bridge) per formare una scatternet, illustrata in figura 4.1. Gli slave possono appartenere a diverse piconet, utilizzando la multiplazione a divisione di tempo, mentre il master di una piconet può essere slave in un altra piconet. Le piconet interconnesse all interno della scatternet formano la struttura portante per 58

69 4 Tecnologie di comunicazione Figura 4.1. Due piconet disposte a formare una scatternet la Mobile Area Network (MANET), che permette a dispositivi che non comunicano direttamente o che sono fuori dalla loro portata di scambiarsi dati tramite diversi passi nella scatternet. Le attuali implementazioni di Bluetooth sono rappresentate principalmente da semplici collegamenti punto a punto tra i dispositivi che sono nel raggio di copertura dell altro. Le specifiche Bluetooth permettono anche soluzioni di connessioni e topologie più complesse. È possibile formare Bluetooth scatternet che realizzano una comunicazione efficiente in più passi con risposte e consumi accettabili per soluzioni end-to-end Comunicazione Quando due dispositivi Bluetooth entrano nello spazio di comunicazione, provano a comunicare tra loro. Se non c è una piconet disponibile si precede alla negoziazione. Un dispositivo diventa master (di solito quello che inizia la comunicazione) e l altro diventa slave. Ogni dispositivo Bluetooth può funzionare all interno di una piconet come master, slave o bridge. I ruoli sono temporanei e cessano con l esistenza della piconet. Il dispositivo master seleziona la frequenza, i tempi (quando ci sono più passi) e l ordine degli slave. Il master è responsabile di alternare slave inattivi verso altri slave in periodi di inattività. Master e slave devono scambiarsi indirizzo e clock per permettere allo slave di unirsi alla piconet. I dispositivi Bluetooth hanno un identificativo unico (Global ID) che viene 59

70 4 Tecnologie di comunicazione usato per creare uno schema a più passi. Il master condivide il suo Global ID e clock con ciascuno slave della sua piconet. Lo slave si deve sincronizzare con il master. Un bridge o gateway Bluetooth collega due o più piconet per una comunicazione a più passi. Il bridge comunica con tutte le piconet a lui connesse sincronizzando il proprio clock con ciascuna piconet, tuttavia può comunicare con solo una piconet alla volta. Il bridge introduce overhead spostandosi da un clock di una piconet al clock di un altra piconet e può diventare un collo di bottiglia. Un bridge può essere slave in tutte le piconet a cui è connesso, o può essere master in una e slave nelle altre. L interconnessione di due o più piconet via bridge determina, come specificato nella sezione precedente, la formazione di una Bluetooth scatternet. Un dispositivo Bluetooth può essere nei seguenti stati: Standby, Inquiry, Page, Connected, Transmit, Hold, Park o Sniff come mostrato in figura 4.2. Un dispositivo è in modalità Standby quando è acceso, ma non è collegato a una piconet. Va nello stato Inquiry quando invia richieste per trovare altri dispositivi a cui potersi collegare. Un master di una piconet esistente può essere nello stato di Page quando invia messaggi per la ricerca di dispositivi che può associare alla sua piconet. Figura 4.2. Stati di un dispositivo Bluetooth 60

71 4 Tecnologie di comunicazione Quando la comunicazione tra il master e il nuovo dispositivo ha successo, il nuovo dispositivo assume il ruolo di slave, entra nello stato Connected e riceve un indirizzo attivo. Lo slave mentre è connesso, può trasmettere dati quando il master lo interroga. Durante la trasmissione dei dati lo slave è nello stato Transmit. Alla fine della trasmissione ritorna nello stato Connected. Lo stato Sniff è uno stato di basso consumo in cui lo slave riposa per un predeterminato lasso di tempo. Lo stato Hold è un altro stato di basso consumo in cui lo slave non è attivo per un certo intervallo di tempo. Non c è trasmissione dati durante lo stato di Hold. Quando un dispositivo slave non ha dati da trasmettere, il master può decidere se metterlo nello stato Parked. Lo slave rilascia il suo indirizzo attivo nella piconet. L indirizzo sarà dato a un altro slave nella piconet che il master ha riattivato dallo stato Parked. Indirizzo e nomi Ad ogni chip Bluetooth costruito viene assegnato in modo permanente un indirizzo di 48 bit globalmente unico, del tutto simile agli indirizzi MAC Ethernet, e di fatto entrambi gli spazi di indirizzi sono gestiti dalla stessa organizzazione, l Autorità di Registrazione dell IEEE. Questi indirizzi vengono cablati nel dispositivo in fase di costruzione e rimangono statici per l intero tempo di vita del chip. Per la comunicazione con un altro dispositivo Bluetooth, bisogna disporre di un qualche metodo per determinarne l indirizzo, poiché esso viene utilizzato in tutti i livelli della pila protocollare Bluetooth, dai protocolli radio di basso livello a quelli applicativi, diversamente da quanto accade per le reti TCP/IP dove l indirizzo hardware su 48 bit viene sostituito da quello IP. Un dispositivo Bluetooth può trasmettere le seguenti informazioni: DeviceName DeviceClass Lista di servizi 61

72 4 Tecnologie di comunicazione Informazioni tecniche, come funzionalità, costruttore, specifiche Bluetooth, ecc. Qualunque dispositivo può inviare una richiesta per cercare altri dispositivi in visibilità a cui connettersi e qualunque dispositivo può essere configurato se rispondere o meno a queste richieste. Se il dispositivo richiedente conosce già l indirizzo dell altro questo risponderà immediatamente inviando le informazioni sopra riportate. Spesso però gli indirizzi sono sostituiti da nomi assegnati dagli utenti o preimpostati dal produttore con la marca ed il modello, e saranno questi ad apparire quando si fa la scansione dello spettro. Questo perché per un umano risulta notevolmente complesso avere a che fare con numeri di 48 bit (così come lo è per gli indirizzi IP) e quindi nonostante l indirizzo fisico sia poi quello che viene effettivamente usato nella comunicazione, si preferisce mostrare all utente un nome user-friendly per identificare una stazione remota. Questo nome è il DeviceName dell elenco precedente. Per quanto riguarda l informazione DeviceClass, essa fa riferimento alle classi di potenza. I dispositivi Bluetooth vengono infatti suddivisi in tre categorie distinte, a ciascuna delle quali corrisponde una potenza di trasmissione radio ed un range d azione del dispositivo Bluetooth, illustrate nell elenco successivo: Classe 1 : per dispositivi a lungo raggio ( metri), con potenza massima in uscita tra 0 dbm (1 mw) e 20 dbm (100 mw); Classe 2 : per dispositivi a raggio medio (10-30 metri), con potenza massima in uscita tra -6 dbm (0,25 mw) e 4 dbm (2,5 mw); Classe 3 : per dispositivi a breve raggio (1-10 metri), con potenza in uscita tra 0 dbm (1 mw) e 0 dbm (1 mw). In merito alla classificazione enunciata e con riferimento ai dispositivi di classe 1 si deve dire che la distanza coperta è del tutto teorica poiché la portata è profondamente influenzata dall hardware USB utilizzato e, cosa del tutto palese, dagli ostacoli posti tra i diversi dispositivi Bluetooth, e in modo minore dai disturbi creati da altre sorgenti 62

73 4 Tecnologie di comunicazione di segnali radio quali cellulari o reti wi-fi. Inoltre, ogni classe Bluetooth determina diversi consumi di corrente del dispositivo. Attualmente la maggior parte dei dispositivi appartiene alle Classi 2 e 3. Inquiry e Paging Le procedure necessarie per creare la piconet sono la inquiry e la paging. La procedura di ricerca dispositivi e di connessione comincia quando un dispositivo Bluetooth entra nello stato inquiry di cui le specifiche Bluetooth ne definisce dei codici di accesso per specificare il tipo di dispositivo che si sta cercando. La procedura di inquiry permette di identificare i dispositivi (e i relativi indirizzi) nel raggio di copertura, ed è attivata da un potenziale master sollecitato da una applicazione o periodicamente da una master già attivo. Il potenziale master invia i pacchetti di inquiry (pacchetti ID contenenti l Inquiry Access Code, IAC) su una particolare sequenza di frequency hopping (cioè una sequenza di frequenze su cui saltare) che copre un sottoinsieme di 32 canali, derivata dal clock del terminale e dal codice scelto, e attende le risposte. Periodicamente i dispositivi nel raggio di ricerca entrano nel sotto-stato Inquiry Scan, nel quale utilizzano la sequenza di frequency hopping del master. Se il dispositivo che esegue l inquiry riceve un messaggio di inquiry, entra nel sotto-stato Inquiry Response e invia un relativo messaggio di risposta che include l indirizzo del terminale remoto (cioè il proprio) e il suo clock di sistema, entrambe informazioni necessarie per stabilire una connessione Bluetooth. Tutti i dispositivi disponibili nel raggio di 10 metri risponderanno perciò all inquiry del master, il quale non risponde bensì continua la fase di inquiry fino al termine di un certo timeout. I potenziali slave che hanno risposto ai pacchetti di inquiring possono decidere di passare allo stato di Page Scan nel caso decidano di connettersi alla nuova piconet. Questo tipicamente richiede che l utente selezioni manualmente il dispositivo Bluetooth desiderato da una lista che la fase di ricerca ha fornito. Quindi, al tempo speso per cercare terminali nell area di ricezione, si somma un tempo indeterminato necessario per permettere all utente la scelta del dispositivo. 63

74 4 Tecnologie di comunicazione Terminata questa fase e ottenuto l indirizzo remoto, il dispositivo locale (cioè il potenziale master) entra nello stato di page e comincia a realizzare il paging delle stazioni che hanno risposto nella fase precedente, per realizzare una connessione con esse e creare così la piconet. Tale procedura viene realizzata una stazione alla volta usando l indirizzo dello slave raccolto nella fase di inquiring (o già noto) e il tempo di clock stimato, per generare una sequenza di frequency hopping (detta appunto page frequency hopping) mediante la quale invia ripetutamente un pacchetto ID che contiene il Device Access Code, DAC (ricavato dai 24 bit meno significativi dell indirizzo dello slave). Se una stazione permette ad altre di connettersi ad esso, entrerà periodicamente nello stato di Page Scan nel quale viene generata una sequenza basata sul proprio indirizzo locale e clock (e sarà quindi sincrona con la page frequency hopping). Da questo stato si passa a quello di Slave Response nel caso in cui lo slave ricevesse il pacchetto ID con il giusto codice DAC. Ad esso può rispondere con un pacchetto Page Response, che farà entrare il master nello stato Master Response in cui questi invia alla stazione un pacchetto FHS (requency Hopping Synchronization) che include il clock e l indirizzo del master. La destinazione invia un secondo pacchetto ID identico ai precedenti per conferma e commuta sulla sequenza di hopping indicata dal pacchetto FHS del master entrando nello stato connesso. Il dispositivo che effettua la procedura diventa definitivamente il master della piconet che viene a costituirsi, e continua eventualmente con il paging delle altre stazioni. Una volta che la connessione è stabilita, la comunicazione inizia con un Poll da parte del master per verificare che la transizione dalla sequenza di hopping della fase di paging alla nuova sequenza abbia avuto buon esito, e per verificarne il corretto utilizzo, a cui lo slave risponde con un qualsiasi tipo di pacchetto come conferma. Se la procedura è stata terminata correttamente i due dispositivi continuano il frequency hopping seguendo uno schema pseudo-casuale condiviso per tutta la durata della connessione Pila Protocollare Le specifiche Bluetooth dividono lo stack di protocolli Bluetooth in tre gruppi: 64

75 4 Tecnologie di comunicazione 1. Transport Protocol group 2. Middleware Protocol group 3. Application group Essi sono raffigurati nella figura 4.3 Figura 4.3. Stack protocollare Bluetooth Il Transport Protocol group permette ai dispositivi Bluetooth di individuare altri dispositivi Bluetooth e di gestire la connessione a livello fisico e logico con i protocolli e applicazioni soprastanti. È da notare che l uso della parola transport nel Trasport Protocol group non indica la coincidenza con il livello di trasporto nel modello di riferimento OSI, piuttosto corrisponde al livello di collegamento e fisico. I livelli Radio, Baseband, Link Manager, Logical Link Control and Adaptation (L2CAP) e Host Controller Interface (HCI) sono raggruppati nel Transport Protocol group. Questi protocolli supportano sia la trasmissione sincrona che asincrona. Tutti i protocolli in questo gruppo sono necessari alla comunicazione tra dispositivi Bluetooth. Il Middleware Protocol group include protocolli di terze parti e standard industriali. Questi protocolli permettono ad applicazioni esistenti e a nuove applicazioni di operare su collegamenti Bluetooth. Protocolli standard industriali comprendono i protocolli Pointto-Point Protocol (PPP), Internet Protocol (IP), Transmission Control Protocol (TCP), 65

76 4 Tecnologie di comunicazione wireless application protocol (WAP), e Object Exchange (OBEX), adottati da Infrared Data Association (IrDA). I protocolli Bluetooth sviluppati da SIG includono: Emulatore di porta seriale (RFCOMM) che permette ad applicazioni legacy di operare sul protocollo di trasporto Bluetooth; Protocollo basato su pacchetti Telephony Control Signaling (TCS) per gestire operazioni di telefonia. Protocollo di Service Discovery (SDP) che permette a un dispositivo di ottenere informazioni sui servizi disponibili sugli altri dispositivi. L Application group comprende applicazioni che utilizzano collegamenti Bluetooth. Possono essere applicazioni legacy sia applicazioni realizzate nell ottica di essere utilizzate con Bluetooth. Più nel dettaglio i livelli del Transport group sono : Livello Radio : Le specifiche di questo livello riguardano principalmente le modalità fisiche di trasmissione. Il modulo radio di un dispositivo Bluetooth è responsabile della modulazione e demodulazione dei dati in segnali a radiofrequenza per la trasmissione senza fili. Livello Baseband : Questo livello definisce come un dispositivo Bluetooth cerca e si collega ad altri dispositivi. I ruoli master e slave che un dispositivo può assumere vengono definiti qui, come il passo di frequenze e la sequenza da utilizzare. Il dispositivo usa per interfacciarsi il time division duplexing (TDD), schema di polling basato su pacchetti. Master e slave comunicano ciascuno nello slot di tempo concordato. Inoltre a questo livello sono definiti i tipi di pacchetti, le procedure di processamento dei pacchetti e le strategie per il rilevamento e correzione degli errori, sbalzi di segnale, cifratura, trasmissione e ritrasmissione di pacchetti. Tutti i pacchetti di livello applicativo vengono frammentati in unità dati Baseband per avere una trasmissione efficiente. 66

77 4 Tecnologie di comunicazione Il livello Baseband supporta due tipi di collegamenti: Synchronous Connection Oriented (SCO) e Asynchronous Connection-Less (ACL). I collegamenti SCO sono caratterizzati da un invio periodico di pacchetto in singolo slot, ed è principalmente usato per trasmissioni voce che richiedono un trasferimento veloce e continuo. Un dispositivo che ha stabilito un collegamento SCO, ha riservati e garantiti certi time slot. I suoi pacchetti sono trattati come pacchetti prioritari e saranno gestiti prima di ogni pacchetto ACL. Un dispositivo con collegamento ACL può inviare pacchetti di lunghezza variabile di 1, 3 o 5 time slot, ma non ha time slot riservati. Livello Link Manager : Questo livello protocollare implementa il Link Manager Protocol (LMP), che gestisce le proprietà di interfacciamento via radio tra i dispositivi e serve per tradurre i comandi provenienti dal HCI in operazioni per il livello baseband. LMP gestisce l allocazione di banda per i dati, gestisce le piconet (link set-up), si occupa dello switch master-slave se fosse necessario, gestisce l allocazione di banda e riserva di risorse per traffico audio, effettua l autenticazione usando un sistema di negoziazione, si occupa del pairing tra dispositivi (utilizzo di un codice concordato), della cifratura dei dati e controlla la potenza utilizzata. Il controllo della potenza include la negoziazione di modalità in low power activity e determina il livello di potenza del segnale. Livello HCI : L Host Controller Interface (HCI) definisce un interfaccia standard per le applicazioni di più alto livello per accedere ai livelli più bassi dello stack. In altre parole è un interfaccia comune tra hardware e software, in quanto i livelli sottostanti sono cablati fisicamente nel dispositivo (denominati modulo Bluetooth), mentre quelli sovrastanti sono implementati in software (denominati host Bluetooth). Questo livello non è richiesto dalle specifiche: il suo scopo è di permettere l interoperabilità tra dispositivi e l uso di protocolli e applicazioni a livello superiore già esistenti. 67

78 4 Tecnologie di comunicazione Livello L2CAP : Il livello Logical Link Control and Adaptation Protocol fornisce l interfaccia tra i protocolli a livello superiore e i protocolli di livello di trasporto. L2CAP supporta il multiplexing di diversi protocolli di alto livello, come RFCOMM e SDP. Questo permette a una molteplicità di protocolli di condividere l interfaccia. L2CAP è anche responsabile di segmentazione dei pacchetti e riassemblaggio e per il monitoraggio e mantenimento del livello di qualità stabilito del servizio. Al di sopra di L2CAP, i restanti livelli dello stack protocollare di Bluetooth non sono più ordinati in modo così lineare. Di particolare rilevanza per quanto riguarda l applicazione sviluppata sono il protocollo di emulazione della porta seriale RFCOMM e il protocollo di ricerca servizi SDP. RFCOMM Le interfacce seriali sono di fondamentale importanza nelle telecomunicazioni e nell elaborazione di dati dove i dispositivi come portatili, PDA o sistemi a comunicazione infrarossa fanno normalmente uso di porte seriali. Il protocollo RFCOMM è un protocollo di trasporto che fornisce per l appunto l emulazione delle porte seriali sopra il protocollo L2CAP garantendo un formato comune per consolidare i diversi formati di comunicazione seriale in uno standard unico. Tale protocollo è spesso riferito come protocollo di rimpiazzo del cavo, essendo specifico per i collegamenti seriali, ed ha il vantaggio chiave di permettere agli sviluppatori di software di usare applicazioni che utilizzano porte seriali con poche modifiche o addirittura nessuna. Questa virtualizzazione della porta COM porta con se operazioni come frammentazione, multiplexing e altre caratteristiche tipiche delle seriali. Il nome del protocollo deriva proprio da emulazione RF-oriented della porta seriale COM. RFCOMM è basato sullo standard dell ETSI TS (usato dai telefoni cellulari GSM per multiplare diversi stream dati in un cavo seriale fisico), anche se in realtà solo una parte dello standard viene effettivamente usato, e si hanno alcuni adattamenti del protocollo riferiti nelle specifiche di RFCOMM. È importante ricordare che il protocollo 68

79 4 Tecnologie di comunicazione in questione è in grado di supportare fino a 30 connessioni simultanee tra due dispositivi. Quanto enunciato fin ora è schematizzato nella figura 4.4 Figura 4.4. Emulazione di porte seriali Il protocollo RFCOMM fornisce approssimativamente gli stessi servizi ed affidabilità che garantisce TCP. In generale le applicazioni che usano TCP hanno a che fare con connessioni punto-punto sui quali possono inviare stream di dati in modo affidabile. A parte le varie proprietà di emulazione di porte seriali che per la maggior parte non interessano ai programmatori, RFCOMM ha all incirca le stesse principali caratteristiche che caratterizzano il protocollo TCP. Inoltre, mentre le applicazioni che usano L2CAP come protocollo di trasporto devono rispettare una certa unità massima di trasferimento (Maximum Transfer Unit o MTU), una connessione RFCOMM è costituita da un flusso di dati, il che semplifica notevolmente la programmazione. La più grande differenza tra questi due protocolli, dal punto di vista dello sviluppatore è senz altro la scelta del numero di porte: mentre TCP supporta fino a porte aperte su una stessa macchina, RFCOMM ne permette solamente 30. Questo ha un impatto significativo su come scegliere quale porte utilizzare per le applicazioni server. Il fatto che 69

80 4 Tecnologie di comunicazione tale protocollo di trasporto sia stato progettato con poche porte disponibili significa che non si possono scegliere arbitrariamente le porte al momento del progetto. La conseguenza di questo è che c è più del 50% di possibilità di collisione tra numeri di porta con sole 7 applicazioni server. In questi casi, per evitare questo inconveniente, lo sviluppatore non deve scegliere in modo arbitrario il numero delle porte, ma utilizzare una risorsa Bluetooth per risolvere tale problema, e cioè il protocollo di ricerca servizi o SDP di cui si parla nel paragrafo successivo. Service Discovery Protocol I protocolli di service discovery permettono a dispositivi ed applicazioni di cercare servizi offerti da altri dispositivi ed applicazioni. Per servizio si intende un entità in grado di fornire informazioni, eseguire un azione o controllare una risorsa per conto di un altra entità. Un servizio può essere implementato in software, hardware o una combinazione dei due. Il Service Discovery Protocol (SDP) fa parte dello stack di protocolli Bluetooth e affronta il problema del service discovery in modo ottimizzato per la natura altamente dinamica delle comunicazioni Bluetooth. Il protocollo SDP si occupa essenzialmente di scoprire i servizi resi disponibili da o attraverso dispositivi Bluetooth; non definisce, invece, metodi per accedere ai servizi. Una volta che un servizio è stato trovato tramite SDP, può essere utilizzato mediante altri protocolli definiti dalla specifica Bluetooth; le modalità d accesso dipendono dal particolare servizio. Analogamente una stazione che offre un servizio Bluetooth, pubblica, in un apposito registro, la descrizione di tale servizio ed i parametri necessari ad utilizzarlo. Il meccanismo di service discovery, schematizzato in Figura 4.5, permette ad un applicazione client di scoprire l esistenza e gli attributi dei servizi forniti da applicazioni server. Per quanto concerne strettamente il Service Discovery Protocol, l interazione avviene tra un client e un server SDP in una o più transazioni, ognuna formata da una richiesta 70

81 4 Tecnologie di comunicazione Figura 4.5. Interazione nel protocollo SDP e una risposta. Ciascuna richiesta o risposta consta a sua volta di un unica PDU (Protocol Data Unit). Un dispositivo Bluetooth può agire sia da client sia da server SDP; se non fornisce servizi, non c è bisogno del server. Ciascun dispositivo può avere un solo server e un solo client, che però possono operare per conto di diverse applicazioni. Le informazioni fornite da un server SDP riguardano solo i servizi offerti dal dispositivo su cui risiede: le specifiche vietano la possibilità che un dispositivo interroghi un altro per cercare i servizi presenti su un terzo dispositivo. Record di servizio Per ciascun servizio che un dispositivo Bluetooth è in grado di offrire, il server SDP possiede uno e un solo record di servizio (service record), che contiene tutte le informazioni ad esso relative. Un record di servizio SDP è costituito unicamente da un elenco di attributi di servizio. Ogni attributo di servizio descrive una singola caratteristica di un 71

82 4 Tecnologie di comunicazione servizio ed è composto da due elementi: 1. un identificativo (ID) di attributo a 16 bit; 2. un campo di lunghezza variabile, il cui formato e significato sono specificati dall identificativo di attributo e dalla classe di servizi a cui il particolare servizio appartiene. Ogni servizio, infatti, appartiene almeno ad una classe di servizi. Una classe di servizi identifica una particolare tipologia di servizi e definisce quali attributi possono essere presenti nel service record per descrivere il servizio, il valore degli identificativi di tali attributi, il loro significato e formato. Il Bluetooth SIG si occupa di standardizzare le classi di servizi. Non è necessario che ogni service record contenga effettivamente tutti gli attributi previsti dalla classe; se però contiene uno degli attributi previsti, il suo formato e il suo significato devono rispettare la specifica. Un fornitore di servizi può indicare ulteriori attributi di servizio, non previsti dalla specifica della classe di servizi, usando uno degli ID liberi. Ad ogni classe di servizi è associato anche un UUID (Universally Unique Identifier, identificativo universalmente univoco). Un UUID nella specifica SDP è definito come un numero intero a 128 bit di cui si assume garantita l univocità ovunque e senza limiti di tempo. Non esiste un registro centralizzato di UUID, ma possono essere creati indipendentemente in maniera distribuita. La specifica prevede degli alias abbreviati a 16 o 32 bit per un intervallo di UUID riservato dal Bluetooth SIG, che ha definito anche l algoritmo di traduzione di tali alias in UUID completi a 128 bit. Alcuni dei più comuni attributi di servizio sono elencati di seguito. ServiceRecordHandle ServiceClassIDList ServiceID 72

83 4 Tecnologie di comunicazione ProtocolDescriptionList BrowseGroupList ServiceAvaliability IconURL ServiceName ServiceDescription ProviderName I primi due dell elenco sono gli unici due attributi che devono esser presenti in tutti i service record. L attributo ServiceRecordHandle identifica ciascun record di servizio in un server SDP mediante un handle a 32 bit. Il valore di un handle è univoco solo all interno di un singolo server. Un unico handle ha il medesimo significato in ogni server SDP, quello che vale 0x e si riferisce al server SDP stesso. Nel corrispondente service record possono essere presenti attributi che indicano la versione di protocollo SDP supportata e i protocolli di livello inferiore utilizzabili per la comunicazione. I valori di handle da 0x a 0x0000FFFF sono inoltre riservati. L attributo ServiceClassID- List, invece, è una sequenza di UUID che identificano le classi di servizi a cui il servizio appartiene. Come detto, quindi, l obiettivo di SDP è permettere ai dispositivi Bluetooth di cercare cosa hanno da offrire gli altri dispositivi in termini di servizi. SDP permette il reperimento dei servizi di interesse in due modalità di ricerca, una per trovare uno specifico servizio (Searching), l altra per vedere quali servizi sono offerti in quel momento (Browsing). Searching : è la transazione di ricerca di un servizio a partire dal valore di uno o più dei suoi attributi. Non è consentita la ricerca per qualsiasi tipo di attributo, ma solo per quelli di tipo UUID, che generalmente sono usati per denotare le caratteristiche distintive di un servizio. Il client effettua una ricerca inviando un search pattern 73

84 4 Tecnologie di comunicazione costituito da uno o più UUID. Il criterio di ricerca si considera soddisfatto dai record di servizio che contengono tra i loro attributi tutti gli UUID specificati, a prescindere da quali attributi effettivamente li contengano e dall ordine. Browsing : è la modalità di ricerca adatta a scoprire quali tipi di servizi sono offerti da un server SDP senza avere alcuna conoscenza a priori. Il meccanismo si basa su un organizzazione ad albero di gruppi di servizi. Ciascun gruppo può contenere servizi o sottogruppi di servizi forniti dal server SDP. Il protocollo SDP può essere usato per diversi scopi, tra cui descrivere quale protocollo di trasporto un server utilizza, per dare informazioni come una descrizione del servizio fornito, chi fornisce tale servizio, oppure il nome del sevizio stesso. Ma l utilizzo principale per cui viene usato SDP è quello preannunciato nella sezione precedente: assegnare in modo dinamico le porte per stabilire una connessione. Nella programmazione per Internet, gli applicativi server fanno tradizionalmente uso di porte conosciute che sono pre-stabilite e concordate in una fase precedente, durante il progetto, e i client utilizzeranno gli stessi numeri di porta per connettersi al server. Il più grande svantaggio di questo approccio è che non è possibile avere due server attivi che utilizzano la stessa porta, ma a causa della relativa gioventù di TCP/IP e grazie al grande numero di porte disponibili, questo non ha ancora rappresentato una considerevole preoccupazione. Come già ricordato in precedenza i protocolli di trasporto di Bluetooth non hanno molte porte disponibili, in particolar modo il protocollo RFCOMM (L2CAP ha all incirca porte non riservate) che ne dispone di 30. Perciò, invece di concordare sulla porta da usare in fase di progetto, l approccio che prescrive Bluetooth è quello di assegnarle dinamicamente durante l esecuzione seguendo un modello publish-subscribe, ovvero pubblica e sottoscrivi. L host gestisce una applicazione server, chiamata per l appunto SDP server e che usa una delle poche porte L2CAP riservate. Alle altre applicazioni server vengono assegnati i numeri di porta durante la loro esecuzione, e registrano una descrizione del servizio che forniscono (oltre che ovviamente i numeri di porta assegnati) 74

85 4 Tecnologie di comunicazione sul server SDP. Le applicazioni client interrogheranno tale server su un certo dispositivo utilizzando la porta riservata per ottenere le informazioni di cui hanno bisogno. Questo solleva la questione di come facciano i client a sapere qual è la descrizione che stanno cercando. Il modo standard stabilito da Bluetooth è di assegnare un numero su 128 bit durante il progetto dell applicazione, chiamato, come già illustrato, UUID. Seguendo questa metodologia standard di scelta dell UUID garantisce la scelta di un numero unico rispetto a quelli scelti da chiunque altro che ha seguito questo modo. Così client e server, entrambi progettati con lo stesso identificativo, possono fornire quest ultimo al server SDP come vincolo di ricerca. Un ultimo punto che vale la pena di menzionare è il fatto che il protocollo SDP non è affatto richiesto per creare una applicazione Bluetooth. È perfettamente possibile comportarsi secondo l approccio di TCP/IP e assegnando in modo statico i numeri di porta e sperare di evitare conflitti, e questo potrebbe essere fatto per risparmiare tempo in ambienti con impostazioni controllate, per esempio in un laboratorio. In ultima analisi, comunque, per creare un applicazione portabile che sia compatibile con la maggioranza degli scenari possibili, essa deve usare SDP e assegnare le porte dinamicamente Librerie BlueZ Il progetto BlueZ si propone come obiettivo generale la realizzazione di un implementazione delle specifiche standard di Bluetooth per Linux. BlueZ venne originariamente sviluppato da Qualcomm Incorporated ed è ora parte di un progetto Open Source con numerosi contributori da tutto il mondo. Il codice è autorizzato sotto la licenza GNU General Public License (GPL), ed è ora incluso nei kernel Linux 2.4 e 2.6. BlueZ fornisce il supporto per i livelli di base e i protocolli di Bluetooth. È inoltre flessibile, efficiente, usa un implementazione modulare e possiede le seguenti caratteristiche: Processamento dei dati in multithread Supporto per più dispositivi Bluetooth 75

86 4 Tecnologie di comunicazione Astrazione di hardware Interfaccia per socket standard a tutti i livelli Supporto per sicurezza Inoltre attualmente BlueZ consiste di numerosi moduli (illustrati anche in figura 4.6): moduli Bluetooth di base per il kernel HCI driver per HCI UART, USB, PCMCIA e Virtual HCI modulo del protocollo L2CAP utility per configurazione e test implementazioni di RFCOMM, BNEP, CMTP e HIDP librerie per SDP I moduli del kernel, le librerie e le utility funzionano perfettamente su molte architetture supportate da Linux incluse piattaforme multi processore: Intel e AMD x86 AMD64 e EM64T (x86-64) SUN SPARC 32/64bit PowerPC 32/64bit Intel StrongARM e XScale processori Hitachi/Renesas SH BlueZ trova supporto in numerose distribuzioni Linux ed è in generale compatibile con qualsiasi sistema Linux presente attualmente: 76

87 4 Tecnologie di comunicazione Figura 4.6. Visione generale di BlueZ Debian GNU/Linux Ubuntu Linux Fedora Core / Red Hat Linux OpenSuSE / SuSE Linux Mandrake Linux È possibile sviluppare software mediante le librerie BlueZ utilizzando diversi linguaggi come Python, Java e C. Python è un versatile e potente linguaggio ad oggetti che fornisce chiarezza sintattica e un meccanismo incorporato di gestione della memoria in modo da permettere al programmatore di focalizzarsi maggiormente sull algoritmo vero e proprio piuttosto che 77

88 4 Tecnologie di comunicazione preoccuparsi di memory leak, dettagli sintattici e analisi di complesse strutture dati. Sebbene Pyhton abbia una grande ed esaustiva libreria standard, il supporto per Bluetooth non fa ancora parte della distribuzione standard. Un buon insieme di API C ben documentate permette agli sviluppatori di creare moduli per estendere le potenzialità del linguaggio e fornire accesso a risorse del sistema operativo che altrimenti non sarebbero accessibili con Python. PyBluez è un estensione modulare di Python scritta in C che provvede al accesso di risorse di sistema con un approccio modulare e ad oggetti. È scritta sia per Windows XP (stack Bluetooth Microsoft) che per GNU/Linux (stack BlueZ). Vi è inoltre un buon numero di API Java per la programmazione Bluetooth attualmente disponibili, standardizzate nelle specifiche chiamate JSR-82, a cui praticamente tutti le implementazioni Java fanno riferimento. Questo rende la portabilità di applicazioni Bluetooth da un dispositivo all altro molto più semplice. Uno svantaggio di usare Java è che JSR-82 è decisamente limitato in quanto non fornisce praticamente nessun controllo sul processo di ricerca dei dispositivi o sulle connessioni dati stabilite. Per esempio, JSR-82 non permette di regolare le semantiche di trasferimento e ottenere informazioni sulla potenza del segnale. Perciò, sebbene JSR-82 sia accettabile per creare semplici applicazioni Bluetooth, non è adatto per la ricerca e per progetti accademici. Tuttavia ci sono svariate ragioni per sviluppare applicazioni Bluetooth in C piuttosto che utilizzando un linguaggio di alto livello come Python: L ambiente Python potrebbe non essere disponibile. Requisiti applicativi vincolanti relativi alla dimensione del programma, velocità e utilizzo della memoria potrebbero precludere l uso di un linguaggio interpretato come Python. Il programmatore potrebbe desiderare un controllo più fine sul dispositivo Bluetooth rispetto a quello che Python fornisce. 78

89 4 Tecnologie di comunicazione Gli obiettivi del progetto potrebbero essere quelli di produrre una libreria condivisa per essere utilizzata da altre applicazioni invece di avere un applicativo a sé stante. Per quanto riguarda lo sviluppo in C, BlueZ è un potente stack di comunicazione con API che permettono all utente di sfruttare completamente tutte le risorse Bluetooth, ma non dispone di una documentazione ufficiale. Gli sviluppatori che intraprendono la programmazione Bluetooth con BlueZ utilizzano le mailing list ufficiali, dove sovente vengono reindirizzati al codice sorgente di BlueZ per capire le API a disposizione 2. Questo è però un processo svantaggioso in termini di tempo poiché permette di rivelare solo poche informazioni per volta, ed è spesso un ostacolo che scoraggia potenziali sviluppatori. 4.3 VoIP VoIP è l acronimo per Voice over IP (ovvero voce tramite protocollo Internet), ed è una tecnologia che rende possibile effettuare una conversazione telefonica sfruttando una connessione Internet o un altra rete dedicata che utilizza il protocollo IP, anziché passare attraverso la rete telefonica tradizionale (PSTN). Ciò consente di eliminare le relative centrali di commutazione e di economizzare sulla larghezza di banda occupata. Vengono instradati sulla rete pacchetti di dati contenenti le informazioni vocali, codificati in forma digitale, e ciò solo nel momento in cui è necessario, cioè quando uno degli utenti collegati sta parlando. Fra gli altri vantaggi rispetto alla telefonia tradizionale si annoverano: minore costo per chiamata, specialmente su lunghe distanze minori costi delle infrastrutture: quando si è resa disponibile una rete IP nessun altra infrastruttura è richiesta nuove funzionalità avanzate l implementazione di future opzioni non richiederà la sostituzione dell hardware 2 Per approfondimenti si veda [14]. 79

90 4 Tecnologie di comunicazione Le conversazioni VoIP non devono necessariamente viaggiare su Internet, ma possono anche usare come mezzo trasmissivo una qualsiasi rete privata basata sul protocollo IP, per esempio una LAN all interno di un edificio o di un gruppo di edifici. I protocolli usati per codificare e trasmettere le conversazioni VoIP sono solitamente denominati Voice over IP protocols Differenze con la telefonia tradizionale Per capire il fenomeno della telefonia su Internet è necessario prendere confidenza con i principi fondamentali che stanno dietro Internet e con le principali differenze di IP rispetto alla cosiddetta rete telefonica fissa (altresì detta PSTN: Public Switched Telephon Network) o quella mobile degli standard di seconda e terza generazione come GSM e UMTS. Sebbene infatti Internet condivida molti aspetti della PSTN, presenta alcune caratteristiche peculiari. La rete telefonica (PSTN) è una rete a commutazione di circuito ottimizzata per le comunicazioni vocali in sincrono e in tempo reale con una qualità di servizio garantita (QoS:Quality of Service). Quando una sessione di comunicazione viene iniziata, si stabilisce un circuito fra la parte chiamante e quella chiamata. La PSTN garantisce la qualità del servizio (QoS) dedicando alla conversazione un circuito full-duplex con una larghezza di banda di 64KHz. Tale larghezza di banda rimane inalterata indipendentemente dal fatto che le parti siano in conversazione attiva o in silenzio. Dato che l ampiezza sopracitata è costante, il costo di una chiamata tramite PSTN è strettamente basato sulla distanza e sul tempo. Internet, invece, è una rete a commutazione di pacchetto e, storicamente, è sempre stata usata per applicazioni dove una QoS variabile poteva essere un parametro tollerabile ( , FTP). Le reti a commutazione di pacchetto non dedicano un circuito (a meno di non considerare i circuiti virtuali) tra le parti in conversazione e perciò non possono garantire la qualità del servizio (sebbene, allo stato attuale delle cose, ci siano numerose iniziative intraprese per raggiungere questo scopo). Per come sono strutturati i protocolli di comunicazione e per come è stata concepita 80

91 4 Tecnologie di comunicazione la rete Internet, il meccanismo primario di costo per un applicazione di telefonia IP non è né la distanza né il tempo, ma l ampiezza di banda usata nella comunicazione. In ogni caso, tale costo è trasparente all utente finale, ditta o privato che sia. Il servizio a tali utenti viene infatti fornito solitamente dagli ISP (Internet Service Provider) che gestiscono direttamente il costo delle connessioni. Per quanto riguarda l utente finale, la telefonia IP diventa dunque il mezzo per comunicare a distanze intercontinentali ai prezzi di una telefonata all interno della locale rete PSTN. Soprattutto per questo motivo il mercato VoIP promette una crescita esponenziale per i prossimi anni in tutti i suoi principali settori (ovvero la telefonia PC verso PC, PC verso telefono, telefono verso PC, e quella classica telefono verso telefono) Qualità di servizio Il problema fondamentale che sta alla base della comunicazione vocale su una rete come Internet è che la gestione dei pacchetti da parte del protocollo IP destinatario non comporta una ricomposizione di questi nell ordine originale. Se alcuni subiscono errori di trasmissione o ritardi vari si capisce come il processo di ricomposizione possa risultare rallentato. Per applicazioni classiche, come ad esempio la posta elettronica, tale ritardo non acquista particolare significato, ma per applicazioni di telefonia, dove l interazione real-time tra le parti è fondamentale, questo può provocare un degradamento notevole nella qualità di conversazione. In generale, il tipo di qualità nella comunicazione che un utente di VoIP si può aspettare dipende in parte dalla velocità della connessione ad Internet che ciascun lato della comunicazione possiede e in parte dal traffico complessivo della rete. Ci sono due fondamentali caratteristiche che determinano la qualità di una connessione telefonica su Internet. La prima caratteristica è il tempo di latenza (Latency). Tale grandezza misura il ritardo che intercorre dal momento che certe parole sono pronunciate da un lato, al momento che queste sono effettivamente sentite dall altro lato, ed è importante mantenere il tempo di latenza dei pacchetti sufficientemente basso, in modo che l utente non debba aspettare 81

92 4 Tecnologie di comunicazione troppo tempo prima di ricevere le risposte durante la conversazione. Spesso gli utenti di VoIP rapportano tale latenza ai ritardi che le normali telefonate subiscono quando parte del circuito è fatto da collegamenti satellitari. La latenza è qualcosa a cui gli utenti possono in genere abituarsi e compensare di conseguenza. L altra importante caratteristica che determina la qualità di una connessione telefonica su Internet è, semplicemente, il grado di rispondenza della voce trasmessa rispetto alla voce naturale di chi parla, ovvero l integrità dei dati. Se certi pacchetti vocali risultano ritardati oltre una certa soglia, il software di telefonia IP cercherà in genere di interpolare i dati mancanti tramite i contenuti dei pacchetti adiacenti. Inoltre durante la trasmissione può cambiare la sequenza dei pacchetti e che alcuni pacchetti possono aver subito perdite o danneggiamenti delle informazioni contenute, ed è perciò compito del software assicurare che lo stream audio (flusso audio) mantenga la corretta coerenza temporale. Naturalmente, più il software ricorre a questa tecnica interpolativa, più la qualità del software risulterà compromessa (distorsione del messaggio vocale). TCP/IP, in sostanza, non garantisce agli utenti la trasmissione di un certo numero di dati in un preciso periodo di tempo. Le prestazioni della rete possono fluttuare di momento in momento. A volte i dati sono trasmessi immediatamente, a volte subiscono ritardi o non sono inviati affatto. Per molti aspetti, i problemi che i progettisti hanno sono simili a quelli incontrati nella progettazione di reti cellulari digitali, dove non ci sono garanzie che i dati arrivino intatti. Quindi i progettisti devono ipotizzare che i livelli sottostanti siano inaffidabili, e compensare gli eventuali errori con le sopracitate tecniche di interpolazione e correzione. Dunque è in genere arduo predire la QoS che ci si può aspettare da una sessione di telefonia in rete, ma, di solito, questa è direttamente correlata all ampiezza di banda che viene sfruttata per la conversazione più che al traffico di rete. Alcune organizzazioni dispongono già da ora di connessioni ad Internet a larga banda. Tali connessioni sono capaci di garantire la qualità sufficiente per fare del VoIP il mezzo standard nelle comunicazioni inter-ufficio a lunga distanza. In definitiva, la qualità nel campo della telefonia IP presenta dei notevoli margini di miglioramento. 82

93 4 Tecnologie di comunicazione Protocolli VoIP La tecnologia VoIP richiede per poter funzionare due tipi di protocollo di comunicazione in parallelo: uno per trasportare la voce sottoforma di dati, in questo caso viene adottato il protocollo RTP (Real-Time Transport Protocol), l altro per la segnalazione e per la sincronizzazione cronologica. In questo caso si possono utilizzare diversi protocolli standard: SIP (Session Initiation Protocol) della IETF; H.323 della ITU; Skinny Client Control Protocol, protocollo proprietario della Cisco; Megaco (conosciuto anche come H.248); MGCP; MiNET, protocollo proprietario della Mitel; IAX, usato dai server Asterisk open source PBX e dai relativi software client. Session Initiation Protocol Il protocollo Session Initiation Protocol (SIP) gestisce in modo generale una sessione di comunicazione tra due entità, ovvero fornisce meccanismi per instaurare, modificare e terminare (rilasciare) una sessione. Esso trova applicazione nella telefonia su IP e nei servizi telefonici supplementari, nella video-comunicazione, nei giochi interattivi, nella messaggistica istantanea. Il protocollo è stato sviluppato, ufficialmente, a partire dal 1999 (RFC 2543 e 3261) per iniziativa di IETF e fa parte della Internet Multimedia Conferencing Suite. Ad oggi l utilizzo prevalente è nella telefonia su IP, per cui SIP è spesso sinonimo di un sistema dedicato a questa applicazione. SIP usa la porta standard 5060, ed è indipendente dal protocollo di trasporto essendo possibile utilizzare sia UDP che TCP, sebbene sia preferibile UDP. SIP è un protocollo 83

94 4 Tecnologie di comunicazione text-based, cioè i messaggi di SIP per il controllo delle chiamate sono in formato testo, e sono molto simili a quelli usati da HTTP per lo scambio di pagine web. Ha una struttura client-server, ma è impiegabile anche in contesti peer to peer, e in entrambe le modalità per instaurare una sessione viene effettuato un three-way handshaking (concettualmente simile a quello che avviene con il protocollo TCP). Per identificare un utente vengono usate le SIP-URI (o indirizzi SIP) che rappresentano lo schema di indirizzamento SIP per chiamare un altro soggetto attraverso il protocollo in questione. In altre parole, un SIP URI è il recapito telefonico SIP di un utente. Il SIP URI assomiglia ad un indirizzo scritto nel seguente formato: SIP URI = dove nome utente può essere rappresentato dal numero telefonico o da un identificativo riconosciuto, mentre host è il dominio o l indirizzo IP. Le cinque funzionalità primarie per stabilire e terminare comunicazioni multimediali sono : 1. User Location : determinazione dei terminali usati nella comunicazione. 2. User Availability : controllo della disponibilità di un utente a partecipare ad una comunicazione. 3. User Capabilities : identificazione dei media e parametri utilizzati. 4. Session Setup : avviso, instaurazione dei parametri di una sessione per entrambi i lati. 5. Session Management : trasferimento e terminazione di una sessione, modifica dei parametri della sessione e invocazione dei servizi. È utile ricordare che SIP (così come H.323) è un protocollo open e quindi chiunque 84

95 4 Tecnologie di comunicazione può sviluppare (gratuitamente e senza autorizzazioni) applicazioni di telefonia, messaggistica e rilevamento della presenza. La stessa cosa non può invece avvenire con il protocollo utilizzato da Skype che, essendo proprietario, è plasmabile soltanto da chi ha prodotto quel codice e programma. Questo purtroppo fa del più diffuso sistema di VoIP Skype appunto, un software veloce e all avanguardia, ma chiuso nel proprio recinto, a meno che non decida un giorno di aprirsi verso altri protocolli di comunicazione. Questo è uno dei motivi per cui si è scelto come software per la terminazione di una chiamata VoIP l applicazione SimpleOPAL, facente parte di un progetto Open Source, denominato OPAL, di cui si tratterà nella sezione successiva OPAL OPAL (Open Phone Abstraction Library) è una libreria di classi Open Source per lo sviluppo di applicazioni che impiegano H.323 o SIP come protocolli per implementazioni VoIP. Esso rappresenta la nuova generazione di OpenH323, il progetto dedicato allo sviluppo collaborativo di una pila protocollare Open Source del protocollo di segnalazione H.323, presentando un architettura diversa. Inoltre non è compatibile solo con H.323 e SIP, ma anche con i nuovi protocolli VoIP, in quanto progettato per essere un infrastruttura per ogni protocollo di segnalazione delle chiamate. OPAL è sviluppato da VoxGratia, un gruppo di programmatori con supporto di altre compagnie, è scritto in C++ e può essere utilizzato sia su Windows che Unix. Per eventuali approfondimenti sul progetto si consiglia di consultare il sito[18]. Il progetto OPAL è stato necessario per superare diversi problemi riscontrati in OpenH323 quali: 1. Inquinamento dello spazio dei nomi o collisione di nomi, problema che si presenta quando lo sviluppatore di una libreria di classi è ostacolato dall uso di nomi simili in un altra libreria. 2. Struttura delle classi poco favorevole e difficoltà di decidere da quale classe far ereditare un discendente necessario per l applicazione. 85

96 4 Tecnologie di comunicazione 3. Supporto possibile solo per il protocollo H Codec con molti parametri, spesso poco chiari. OPAL è stato estratto da OpenH323 dopo l astrazione di numerose classi e dopo avere lasciato le specifiche dei protocolli (come H.323 o SIP) alle classi discendenti. Il risultato è caratterizzato da un architettura stream-based e soprattutto espandibile, cioè è presente un supporto esplicito per l aggiunta di nuovi protocolli. Attualmente i progetti OPAL e OpenH323 vanno in parallelo poiché molte applicazioni utilizzano ancora OpenH323, che quindi non è ancora stato deprecato. Un applicazione sviluppata nell ambito del progetto OPAL è SimpleOPAL e permette di ricevere ed effettuare chiamate VoIP. Struttura interna di SimpleOPAL I principali moduli nella parte della segnalazione sono OpalManager : il Manager è la radice dell albero di appartenenza e gestisce diversi punti terminali (endpoint) ed è responsabile del meccanismo di creazione delle chiamate. Tutti gli endpoint sono logicamente collegati a tale classe. OpalEndPoint : è la classe padre dei vari endpoint divisi dipendentemente dal protocollo. Attualmente sono implementati i seguenti punti di terminazione: 1. H323 End Point per il protocollo H SIP End Point per il protocollo SIP 3. PCSS End Point per PC Sound System 4. PSTN End Point come gateway 5. POTS Endpoint per la telefonia tradizionale Sono incluse funzioni di callback che possono essere re-implementate dalle classi discendenti per tenere traccia e controllare i flussi di chiamata. 86

97 4 Tecnologie di comunicazione OpalCall : appartiene a OpalManager ed ha lo scopo di unire due o più connessioni in una chiamata. OpalCall ottiene la connessioni dagli endpoint. Un istanza della classe OpalManager può avere un infinito numero di endpoint, ma ad un applicazione è permesso avere un solo OpalManager. In sintesi i passi svolti per l instaurazione di una chiamata sono: 1. La classe EndPoint ascolta su una specifica porta in attesa di chiamate entranti. 2. SIPEndPoint riceve una chiamata. 3. OpalManager cerca un PCSSEndPoint o un SIPEndPoint e gli demanda di creare una connessione. 4. OpalManager infine unisce gli endpoint in una istanza di OpalCall. La figura 4.7 mostra come i vari attori della comunicazione interagiscano tra loro. Per stabilire un trasferimento Audio/Video, vengono invece usate istanze di classi che ereditano dalla classe OpalMediaStream. Esse permettono di trasferire dati da e per sessioni RTP, file e dispositivi video. La classe OpalMediaPatch è invece il thread di controllo che effettivamente trasferisce i dati da un istanza sorgente di OpalMediaStream a un sink, ovvero destinazione. OpalMediaPatch è anche incaricata di richiamare i codec necessari, controllando se il sink supporta quelli utilizzati. 87

98 4 Tecnologie di comunicazione Figura 4.7. Diagramma dei principali moduli di OPAL 88

99 Capitolo 5 Analisi e design architetturale 5.1 Introduzione Nei capitoli precedenti sono state poste le basi teoriche ed esposti i dettagli tecnici che permettono di comprendere gli aspetti del progetto descritto in seguito. I prossimi tre capitoli sono infatti dedicati ad un descrizione il più possibile esaustiva del lavoro prodotto ed hanno l obiettivo di spiegare in modo chiaro ed accessibile l applicazione, considerata la sua piattaforma ed il contesto legato alla comunicazione telefonica su Internet. Questo capitolo si colloca in una fase propedeutica di presentazione del software nella quale si pone quest ultimo nell attuale scenario di applicativi per la telefonia su Internet, ovvero VoIP. Inoltre in esso vengono esposte le modalità di utilizzo e le specifiche del progetto maturate nella fase precedente al progetto ed affinate in seguito a questo stadio, esaminando i vincoli e le caratteristiche in un prospetto generale che comprende sia il programma a lato client, che quello a lato server. Infine si conclude il capitolo introducendo i principali requisiti tecnici e di usabilità che si è cercato di soddisfare nella successiva implementazione, per quanto riguarda lo streaming multimediale, la connessione Bluetooth ed altri aspetti inerenti. 89

100 5.2 Contesto applicativo 5 Analisi e design architetturale Ad oggi il numero di applicazioni VoIP che vengono offerte è innumerevole. Non passa settimana senza che venga lanciato un nuovo servizio di telefonia VoIP pubblicizzato come il migliore al prezzo più basso, anche se al di là di questa patina pubblicitaria le differenze possono essere notevoli. Effettivamente la possibilità di integrazione con altri servizi (instant messaging, posta elettronica ecc.), la flessibilità dei dati digitali (permettere compressione, criptazione e maggiore robustezza) e soprattutto i costi competitivi rispetto alla telefonia fissa sono fattori che risultano essere piuttosto appetibili per i consumatori e permettono così un rigoglioso fiorire di applicazioni per la telefonia su protocolli Internet, come Skype, Ekiga, Google Talk, Asterisk PBX per citare i più famosi. Gli scenari di utilizzo variano in base al tipo degli endpoint della chiamata VoIP, e cioè se i punti terminali della sessione sono dei personal computer o dei telefoni. Naturalmente ogni applicativo permette di effettuare una chiamata voce o dati tra due client su PC, ma non sempre due applicativi sono compatibili tra loro e questo può essere un problema vista la costellazione di proposte al riguardo. Nonostante questa problematica e quelle legate alla QoS dovute alla natura non orientata alla connessione di Internet, sembra essere comunque in crescita l utilizzo di queste applicazioni per i costi decisamente bassi. Il leader indiscusso in termini di notorietà e diffusione è Skype che ha guadagnato la prima posizione con campagne marketing milionarie e bombardamenti mediatici giornalieri, ma che per quanto riguarda il servizio SkypeOut non è certo il più competitivo. Tra tutti gli innumerevoli servizi che sono apparsi negli ultimi 2-3 anni, Skype si é nettamente distinto dagli altri perché é stato il primo a offrire chiamate gratuite per un certo numero di destinazioni, riuscendo con questa strategia di marketing a accaparrarsi una consistente fetta di mercato. Ciò che è di interesse è notare come nel tempo sono aumentate le offerte di telefoni USB che permettono di utilizzare i vantaggi della telefonia su Internet pur utilizzando uno strumento domestico a cui l utente medio è ormai abituato da anni, e cioè un apparecchio telefonico. La quasi totalità di questi apparecchi è compatibile con Skype, essendo 90

101 5 Analisi e design architetturale quest ultimo il più diffuso tra i client VoIP. Più di 100 milioni di persone, infatti, hanno installato Skype sui propri PC o Mac, ma proprio il software VoIP più conosciuto e apprezzato per facilità d uso e funzionalità avanzate rischia di arrivare in ritardo dove alcuni concorrenti sono già da tempo: i telefoni cellulari Scenario applicativo per cellulari Mentre Skype continua a ritardare l uscita della propria versione per cellulare, diversi produttori di software hanno lanciato soluzioni VoIP per dispositivi mobili, cellulari o smartphone (in generale è richiesto quantomeno un telefono compatibile con le reti di seconda o terza generazione, UMTS o GPRS). Alcuni offrono funzionalità aggiuntive come instant messaging e compatibilità con i software VoIP più diffusi (Skype, Google Talk, Gizmo...), altri si limitano ad offrire prezzi bassi per chiamate internazionali. Recentemente Jajah ha lanciato Jajah Mobile Suite, estensione mobile del proprio servizio, che solitamente funziona attraverso una pagina web dalla quale inserire il proprio numero e quello del destinatario della chiamata (Jajah fa squillare il cellulare del chiamante e lo mette in contatto con l altra parte). Oggi è possibile attivare una chiamata direttamente dal cellulare con una piccola applicazione Java o Symbian (tramite una connessione dati UMTS o un semplice SMS). Conveniente solo per le chiamate da o verso l estero (una chiamata dall Italia a New York costa meno di 2 euro contro i 6,5 di Vodafone, TIM e Wind), il servizio si rivela una valida alternativa all utilizzo di calling-cards ed altre soluzioni che consentono di evitare le costosissime tariffe di roaming degli operatori mobili. Talkster è un servizio VoIP per cellulari simile a Jajah, ma non richiede l installazione di alcun software (basta dirigersi su m.talkster.com con il browser del proprio cellulare). Il servizio, ancora in fase di sviluppo iniziale, permette di chiamare utenti MSN, Gizmo, Google Talk e telefoni tradizionali, con il consueto risparmio se si chiama all estero. A differenza di Jajah, permette anche di chiamare un numero nazionale invece di farsi richiamare sul cellulare ed integra funzionalità di presence management (la possibilità di vedere quando i propri contatti sono online). 91

102 5 Analisi e design architetturale Jajah e Talkster non sono gli unici a voler portare il VoIP sui cellulari: se Skype affronta problemi relativi alle ridotte capacità di calcolo di alcuni dispositivi e problemi di latenza derivanti dall utilizzo di reti 3G, Fring è riuscito nell impresa e ha reso disponibile un software per telefoni con sistema Symbian che sfrutta protocolli proprietari, per garantire qualità della chiamata e ridotti consumi energetici, e permette di chiamare utenti Fring, Skype e Google Talk. Fring offre un client VoIP vero e proprio, con funzionalità di instant messaging, gestione della presenza, compatibilità con due tra i software VoIP più diffusi e la possibilità di fruire del servizio quasi ovunque, grazie alla copertura 3G. Le soluzioni proposte da EQO e SoonR, permettono di usare Skype su molti telefoni cellulari, rispettivamente tramite un applicazione Symbian e tramite un browser WAP. Questi servizi richiedono ai propri utenti di installare un apposito software sui propri computer collegati a Skype e sfruttano il loro credito SkypeOut per metterli in contatto con i destinatari delle chiamate (in sostanza attivando una conference call tra il proprio account Skype collegato sul PC, il telefono cellulare del chiamante ed il destinatario della chiamata). Leggermente diverso l approccio di iskoot, che ha sviluppato un applicazione ed una soluzione client-server proprietaria che permette di usare Skype dai telefoni cellulari. Come per i servizi appena descritti, è necessaria una connessione dati 3G (o WiFi, per la nuova versione in beta) per mantenere aggiornata la contact list, le informazioni sulla presence dei contatti ed avviare una conversazione. Quando si chiama un contatto Skype o SkypeOut, il cellulare chiamerà il numero del gateway di iskoot, che lo collegherà all utente Skype desiderato. Per le chiamate in entrata, invece, iskoot sfrutterà il credito SkypeOut del proprio utente per richiamarlo sul suo telefono cellulare. A differenza di EQO o SoonR, non è necessario tenere il PC acceso e collegato a Skype, tuttavia una chiamata tramite iskoot costerà tanto quanto una normale chiamata da cellulare. Se è necessaria una connessione dati 3G, e quindi un piano tariffario flat per non incorrere in spese esorbitanti per pochi minuti di attività, molti potrebbero trovare più interessante la proposta di Fring, senza dubbio più economica visto che, una volta collegati, le chiamate ad utenti Skype (o Google Talk) viaggiano su Internet e sono quindi gratuite 92

103 5 Analisi e design architetturale (escluso chiaramente il costo del collegamento 3G). Tuttavia, per quanto Fring sia una delle poche soluzioni VoIP mobile in grado di definirsi completo in termini di esperienza di comunicazione (soprattutto se confrontate con altre orientate esclusivamente ad offrire prezzi vantaggiosi), rimane difficile immaginare che software simili possano raggiungere un pubblico di massa utilizzando esclusivamente collegamenti 3G. Sarà attratto da soluzioni simili solo chi è fornito dal proprio operatore di un piano tariffario dati flat, in mancanza del quale una chiamata tra utenti Fring o Skype potrebbe costare oltre 3 euro al minuto. Piani tariffari di questo tipo sono ancora poco diffusi nel nostro paese e non raggiungono grandi numeri nemmeno negli Stati Uniti. Oltre alla scarsa convenienza, il problema è la facilità con cui gli operatori di telefonia mobile possono impedire o scoraggiare l utilizzo di applicazioni VoIP sulle loro reti dati, sulle quali sono in grado di esercitare un controllo assoluto, senza alcuna garanzia per l utente ed alcun rispetto per la neutralità della rete. 5.3 Specifiche del progetto Il progetto sviluppato durante la tesi si colloca in questa costellazione di strumenti per la comunicazione telefonica attraverso la rete Internet. La principale differenza che emerge confrontando le attuali soluzioni con gli obiettivi e i disegni progettuali di questo lavoro sta nel fatto che le applicazioni viste nel paragrafo richiedono copertura 3G per effettuare una chiamata VoIP in quanto sfruttano, a tale scopo, la connessione Internet da cellulare offerta dallo standard di terza generazione. Questo comporta chiaramente dei costi di connessione, ma il vantaggio di potere chiamare, utilizzando la tecnologia VoIP in qualsiasi momento e soprattutto in qualsiasi luogo. L applicazione che viene presentata nasce invece in un ottica di integrazione di tecnologie che consentono di automatizzare una comunissima operazione quale può essere l effettuazione di una chiamata telefonica, e rientra perciò in un ambito domestico che è tipico della domotica. Lasciando ad altre trattazioni i dettagli di questa scienza, è interessante notare come questo progetto permette da un lato di sfruttare i vantaggi legati al 93

104 5 Analisi e design architetturale risparmio economico sulle tariffe delle chiamate tipico di VoIP, e dall altro di utilizzare un oggetto personale come il proprio cellulare a cui si è abituati ormai da anni. Se già le applicazioni attuali facevano affidamento sulla dimestichezza che un utente medio ha con un telefono fisso, è facile intuire che nel caso di telefonia mobile oltre che avere un maggiore livello di familiarità dovuto alla più recente esplosione dell uso di cellulari, è anche possibile evitare l acquisto di un apparecchio ad-hoc per la fruizione di determinati servizi. È sufficiente infatti essere dotati di un telefono cellulare compatibile con il software sviluppato 1 e senza alcun costo si è in grado di chiamare un altro client VoIP veicolando la voce su Internet. In definitiva si vuole fornire uno strumento per sfruttare la tecnologia VoIP in modo friendly, cioè rivolto a quegli utenti non troppo abituati all uso di un PC, e per rendere più utilizzabile tale servizio anche per i più esperti, permettendo di disaccoppiare l applicazione VoIP presente sul PC dall utente, il quale si ritroverebbe semplicemente ad avere a che fare con un semplice applicativo sul proprio cellulare Symbian. Come è mostrato in figura 5.1 il terminale mobile e il PC sono connessi e comunicano mediante una connessione Bluetooth che fornisce il canale per veicolare le informazioni multimediali come la voce, e quelle di segnalazione per gestire e controllare la chiamata. Ad oggi una soluzione del genere è del tutto innovativa, e renderebbe il cellulare un device remoto per parlare e dialogare via VoIP pur rimanendo lontani dal proprio PC poiché, grazie alla tecnologia di trasmissione Bluetooth, è teoricamente possibile allontanarsi fino a 100 metri dal computer su cui è installato il software VoIP. Un importante specifica che si propone di garantire una maggiore usabilità e familiarità con il software è la trasparenza. L obiettivo è, come già è stato detto, è semplificare l approccio dell utente, mostrandogli e dandogli le funzionalità tipiche a cui è già abituato quali: Finestra di dialog e suoneria all ingresso di una chiamata. Informazione sulla durata della chiamata. 1 cioè la cui piattaforma è la stessa su cui è stato implementato il client. 94

105 5 Analisi e design architetturale Aggiornamento del registro di chiamate in caso di chiamata persa. Inoltre è importante ricordare che al telefono cellulare viene inoltrata la voce dal PC che è il vero terminatore e gestore della sessione VoIP. In questo modo il cellulare non ha bisogno di una connessione 3G e quindi può funzionare anche senza carta SIM. Figura 5.1. Scenario di utilizzo di BlueVoice Modalità Walkie-Talkie In fase di sviluppo, per ragioni implementative che verranno chiarite nel capitolo 6, è stata sviluppata una funzionalità aggiuntiva o, per meglio dire, una diversa modalità di utilizzo che vede il telefono cellulare collegato, non ad un applicazione che risiede su un PC, bensì ad un altro terminale mobile su cui è installata l applicazione Symbian. Essa è stata definita modalità Walkie-Talkie per l evidente analogia con gli apparecchi di ricetrasmissione portatili, anche se di fatto non ha la caratteristica, per lo meno in fase di design, del metodo di comunicazione Push-to-Talk, in quanto non è un canale half duplex commutato di volta in volta dalla pressione di un tasto. Ciò che rappresenta questa modalità è una chiamata telefonica (e quindi full-duplex) di basso raggio, in quanto basata sulla connessione Bluetooth e quindi, stando alle classi di potenza specificate nel paragrafo 4.2.2, 95

106 5 Analisi e design architetturale dell ordine di qualche decina di metri indoor (considerando che tipicamente un cellulare monta un dispositivo Bluetooth di classe 2). Ovviamente la casistica di utilizzi di questa funzione è decisamente ridotta considerata la ristretta portata che garantisce Bluetooth, ma avrebbe il vantaggio di essere totalmente gratuita e quindi potrebbe fungere da servizio home oriented come controllo remoto degli ambienti o appunto come Walkie-Talkie. 5.4 Visione generale del progetto BlueVoice Il software sviluppato è denominato BlueVoice, e si compone di un applicazione Symbian per la piattaforma Serie 60 2 Edizione, Feature Pack 2, ovvero per il sistema operativo Symbian v8.0a installata su un relativo telefono cellulare, ed un server lato PC. Quest ultimo ha il compito di accettare le connessioni provenienti dal client VoIP sull apparecchio mobile e richiamare le opportune primitive per iniziare ed in generale gestire la chiamata verso un altro end-point. La generica architettura, schematizzata in componenti funzionali e di struttura, è illustrata in figura 5.2 Nei successivi paragrafi verrano presentate le caratteristiche funzionali dei due moduli del progetto stabilite in fase di design ed eventualmente modificate e formate in corso d opera. Verranno tralasciati i dettagli implementativi in quanto se ne fornirà una trattazione esaustiva nel capitolo Applicazione lato client In questa sezione viene presentata l applicazione client dal punto di vista funzionale e architetturale, quindi enunciandone le diverse potenzialità che in fase di progetto vogliono essere raggiunte. 96

107 5 Analisi e design architetturale Figura 5.2. Architettura generale di client e server BlueVoice Installazione e avvio L applicativo client è di facile installazione e utilizzo, e necessita semplicemente di un dispositivo Bluetooth montato sul cellulare e di un adattatore Bluetooth sul PC per stabilire un canale di trasmissione col terminale. Per installare il client è sufficiente seguire le istruzioni elencate nel paragrafo e cioè inviare il file BlueVoice.sis al telefono mediante un messaggio dal PC o utilizzare lo strumento Nokia PC Suite cliccando su Installazione applicazioni e selezionare l appropriato dispositivo mobile su cui installare il file. Queste due operazioni possono essere svolte mediante Bluetooth oppure mediante il cavo PC-cellulare fornito in dotazione all acquisto del telefono. Una volta terminato l invio, un wizard di semplice utilizzo verrà avviato sul cellulare; è necessario seguire le istruzioni per portare a compimento l installazione. Ultimata questa procedura l applicazione si troverà sul menu principale, riconoscibile per l icona e 97

108 5 Analisi e design architetturale il nome BlueVoice a fianco, e sarà avviabile semplicemente premendo il tasto centrale su tale icona. Modalità client e server Nel paragrafo è già stato preannunciata la possibilità del client VoIP presente sul telefono di collegarsi con un altro cellulare simile che abbia un dispositivo Bluetooth. In pratica il telefono può agire anch esso secondo due diverse modalità: Client : in questo caso il cellulare diventa l iniziatore della connessione nel senso che assume il ruolo attivo di ricerca di possibili server, cioè di dispositivi Bluetooth che forniscono il servizio richiesto, appositamente pubblicato mediante il meccanismo publish-subscribe visto nel paragrafo Se la ricerca dei dispositivi va a buon fine il client verifica che, tra tutti i dispositivi Bluetooth trovati, vi sia un server Blue- Voice. In caso affermativo stabilisce la connessione con esso aprendo due canali Bluetooth RFCOMM unidirezionali, uno per il traffico da cellulare a PC e l altro per il cammino inverso, creando in questo modo un canale virtuale bidirezionale. Questa modalità viene attivata accedendo alle opzioni offerte dall applicazione e premendo su Discover devices. Server : è possibile fare funzionare il telefono come server BlueVoice premendo su Start slave, il che permetterà ad altri cellulari in fase di scansione del canale wireless di rilevare il suddetto terminale disponibile per una connessione. Esso inizia una procedura di apertura di due socket Bluetooth su cui si mette in ascolto e una di pubblicazione del servizio BlueVoice che è in grado di fornire, al termine della quale si mette in attesa di una richiesta da parte di un eventuale client. In questo modo è possibile attuare il tipo di comunicazione cellulare-cellulare che consente l interazione tra i due dispositivi sfruttando semplicemente il canale Bluetooth e non la tratta sulla rete Internet. Al termine di entrambe queste procedure, colui che ha cominciato la fase di inquiry, cioè di ricerca dei dispositivi, diventerà Master della comunicazione, mentre l elemento 98

109 5 Analisi e design architetturale passivo che subisce la ricerca sarà lo Slave (vedi paragrafo 4.2.2). Di fatto questi ruoli, come si vedrà in seguito, sono tutto sommato interscambiabili e paritetici una volta effettuato il collegamento e non sono discriminanti di particolari funzionalità. Dopo la connessione del cellulare con una stazione fissa o mobile viene notificato all utente l avvenuto collegamento e il tipo di modalità (Walkie-Talkie o telefonata VoIP), e sono modificate le opzioni mediante le quali ci si interfaccia al software. A questo punto è possibile iniziare e ricevere chiamate. Ciclo di vita di una chiamata Una volta avviato BlueVoice e al termine di una connessione con un dispositivo server, l applicazione agisce come un demone attivo in background in ascolto sui canali Bluetooth utilizzati, in modo che sia comunque possibile utilizzare l apparecchio normalmente accedendo a tutte le risorse del cellulare e alle sue funzionalità per altri scopi ed utilizzi. Nel caso l utente voglia iniziare la chiamata è sufficiente accedere alla funzione Start call presente nel menu delle opzioni. Nella modalità telefonata VoIP la scelta di inizio chiamata causerà la visualizzazione di un dialog 2 di richiesta del numero telefonico da digitare. Se si sta usando il programma per dialogare con un altro cellulare, essendo questi l unico end-point presente, non è necessario chiedere all utente di immettere un numero telefonico, e pertanto tale fase sarà omessa. Una volta stabilita la connessione audio l utente può comunicare con l altro terminale in quanto la sua voce viene registrata dal microfono incorporato sul dispositivo ed inviata sul canale Bluetooth in uscita, mentre l altro canale riceve i pacchetti voce inviati e li manda all hardware dell altoparlante come in una telefonata normale, e come illustrato in figura 5.3 Al termine della conversazione l utente può decidere di interrompere la chiamata premendo su Stop call o vedersi interrotta la comunicazione da un evento di fine chiamata 2 I dialog sono finestre usate dal programma o dal sistema operativo per visualizzare informazioni all utente, o per ottenere risposte e input se richiesti. 99

110 5 Analisi e design architetturale Figura 5.3. Schema logico della funzionalità full-duplex causato dall altro host. In entrambi i casi l interruzione provoca la visualizzazione di una finestra che indica la durata della telefonata in termini di ore, minuti e secondi. Chi riceve verrà invece notificato dell ingresso di una chiamata mediante lo squillo del telefono e da un dialog che visualizza il nome del chiamante e fornisce la possibilità di accettare o rifiutare la connessione. È da notare che tale finestra viene presentata all utente anche se questi non sta usando l applicazione, poiché BlueVoice è attivo in background e l arrivo di una chiamata scatena l evento di notifica. In caso di risposta affermativa si entra nello stato connesso di cui si è già parlato in precedenza, in caso contrario il chiamante è informato del rifiuto della chiamata. Se l utente chiamante termina la chiamata prima che dall altro lato qualcuno possa rispondere, o in alternativa se il chiamato non risponde entro 20 squilli, al chiamato verrà 100

111 5 Analisi e design architetturale presentato un dialog che lo informa del numero di chiamate perse e lo interroga circa la volontà di visualizzare i dati delle chiamate perse. Se viene premuto il softkey 3 Visualizza, ciò che appare all utente è una lista di nomi rappresentanti l identificativo dei chiamanti a cui non è stata data una risposta. Inoltre questi nominativi vengono aggiunti nel registro di sistema delle chiamate perse e accessibili usando l opportuna applicazione presente sul menu generale del telefono. Seguendo uno schema a blocchi logico il ciclo di vita della chiamata può essere raffigurato nel diagramma 5.4. Si noti come tale flusso è del tutto analogo a quello di una chiamata sulla rete telefonica mobile. Questa analogia è uno degli obiettivi del progetto in modo da minimizzare la differenza con una procedura a cui si è familiari e da massimizzarne l usabilità e la trasparenza. Usabilità Una delle considerazioni più significative da esprimere in merito all usabilità del software è legata all impossibilità di accedere alle librerie di sistema di un cellulare Symbian. Questo comporta l impossibilità di avviare l applicazione al boot del cellulare (come è possibile col file initrd di Linux), il che renderebbe ancora più efficiente e trasparente l utilizzo del programma Applicazione lato server Il programma che gira sul PC è in realtà la modifica del progetto Open Source SimpleOPAL già introdotto nel paragrafo Tale software deve essere opportunamente compilato in ambiente Linux e permette, in quanto fornisce i sorgenti di tutta l applicazione, di essere modificato e migliorato. SimpleOPAL è un programma avviabile da riga di comando e senza interfaccia grafica che permette di ricevere e inoltrare chiamate VoIP fornendo come numero telefonico un opportuna SIP-URI, il cui formato è esposto nel paragrafo Vedi paragrafo

112 5 Analisi e design architetturale Figura 5.4. Diagramma di flusso del ciclo di vita di una chiamata In questa sezione non si tratterà delle caratteristiche di base di SimpleOPAL (sebbene 102

113 5 Analisi e design architetturale ne verrano citate alcune e se ne darà una rapida introduzione), bensì saranno analizzate le modifiche riportate al software al fine di realizzare una struttura coerente e funzionale con quella creata per il telefono cellulare. L obiettivo è quello di integrare SimpleOPAL con il client del cellulare, in modo che funga da tramite tra i due soggetti della comunicazione, uno in contatto con SimpleOPAL attraverso Internet, l altro mediante Bluetooth. Il sistema complessivo di BlueVoice è illustrato in una sua topologia nella figura 5.5 Figura 5.5. Schema di chiamata BlueVoice-telefono VoIP La questione più immediata da risolvere è indubbiamente quella legata all implementazione di meccanismi basati sulla tecnologia Bluetooth per permettere la comunicazione tra il soggetto dotato di dispositivo mobile (vedi soggetto 2 in figura 5.5) e il PC, o meglio l applicativo VoIP SimpleOPAL. Quest ultimo fornisce semplicemente le primitive per gestire una chiamata attraverso Internet (cioè la comunicazione col soggetto 1). A tale scopo è necessario avere due thread paralleli all esecuzione di SimpleOPAL, ognuno dei quali gestisce uno dei due canali Bluetooth unidirezionali che sono portatori dei pacchetti voce da e per il telefono cellulare. In questo modo SimpleOPAL da un lato diventa server Bluetooth in attesa delle connessioni dall utente mobile esattamente come avveniva nel caso in cui l applicazione lato client fungeva da server (vedi 5.4.1), e dall altro lato agisce da client e server per le chiamate VoIP. Anche in questo caso si mette in ascolto sui canali Bluetooth e pubblica il servizio BlueVoice che è in grado di fornire e i numeri di porta, per poi mettersi in attesa di una richiesta da parte di un eventuale client. 103

114 5 Analisi e design architetturale In definitiva BlueVoice lato server è sostanzialmente costituito da SimpleOPAL senza alcuni aspetti non utili al progetto, come la trattazione del segnale video, e con l aggiunta dei due thread. 5.5 Requisiti progettuali L applicazione BlueVoice è di tipo multimediale, e in quanto tale deve sottostare a determinati vincoli legati al corretto funzionamento e all usabilità delle sue funzionalità. Inoltre sono da tenere in conto alcune considerazioni di altra natura che vanno ad impattare sull uso più o meno user-friendly del prodotto finale Ritardi e jitter Con streaming di contenuti multimediali si fa riferimento ai media, audio e video, che vengono ricevuti in un flusso continuo e tipicamente consumati dall utente finale (cioè visualizzati, riprodotti o elaborati) mentre il fornitore del servizio li sta inviando in tempo reale. Di fatto quindi il nome streaming si riferisce più al metodo di trasmissione piuttosto che al contenuto stesso, e tende a sottolineare l idea di flusso che è legata all invio dei dati, poiché se questi ultimi non vengono utilizzati secondo precise scadenze temporali sono da considerarsi inutili e quindi scartati. Questo paradigma di trasmissione è quindi palesemente in contrasto con le metodologie adottate, per esempio, per il trasferimento di file, dove l utilizzo del media è possibile solo al termine dell invio. Ciò è impensabile per servizi video o, come ci si focalizza in questa trattazione, per servizi di telefonia in cui i ritardi di trasmissione possono avere serie ripercussioni sull interattività della comunicazione e sulla corretta fruizione dei contenuti da parte dell utente. I ritardi tra la produzione dei pacchetti voce e l effettiva riproduzione a lato del ricevitore possono avere molteplici cause e, se non controllati, possono arrivare a livelli intollerabili a scapito dell intellegibilità del discorso in atto. Per assicurare una buona 104

115 5 Analisi e design architetturale qualità audio si sono quindi dovuti considerare tutti i ritardi presenti nella totalità della tratta tra i due utenti terminali. Figura 5.6. Rappresentazione della tratta totale tra utenti finali Facendo riferimento alla figura 5.6 è possibile evidenziare lungo ogni tratto tutti i possibili tipi di ritardi che vanno ad incidere su quello complessivo end-to-end: Ritardi di Propagazione : tempi dovuti alla trasmissione effettiva dei pacchetti dati e di controllo sui canali fisici: Canale Bluetooth, ovvero i tratti 1 e 3 della figura. Rete Internet che nella figura è schematizzata nel segmento 2 e che è causa di ritardi fortemente variabili. Ritardi di Elaborazione : tempi di sintesi dei dati oppure tempi causati dal trattamento dei dati e da operazioni compiute su di essi e quindi legati ai tempi di elaborazione del sistema operativo: Tempi di sintesi vocale legati alla frequenza di campionamento nei punti A e B Tempi di codifica della voce nei punti A1 e B1 o eventualmente agli estremi della comunicazione (punti A e B) 105

116 5 Analisi e design architetturale Ritardi di Buffering : tempi derivati dalla memorizzazione a lato ricevitore (e quindi nei punti A o B) di un certo numero di pacchetti ricevuti prima che ne avvenga effettivamente l utilizzo. In particolare l introduzione di memoria presso il ricevitore e di un ritardo iniziale prima della riproduzione ha lo scopo di eliminare i problemi causati dal jitter 4. Il fatto che i pacchetti sperimentino in rete dei ritardi differenti (i pacchetti possono seguire percorsi differenti gli uni dagli altri), causa dei problemi quando si vogliano riprodurre i pacchetti immediatamente dopo l arrivo ( on the fly ) a causa dei rigidi vincoli di riproduzione da rispettare. Con l introduzione di un buffer nel quale i pacchetti vengano accumulati all arrivo e dal quale vengano prelevati, dopo un certo ritardo, con frequenza costante per essere avviati alla riproduzione, si riesce a svincolare la velocità di arrivo da quella di riproduzione (quest ultima coincidente con la velocità di prelievo dal buffer). La probabilità che, in corrispondenza dell istante di riproduzione di un campione, il pacchetto che lo contiene sia effettivamente presente presso il Client aumenta, mentre il jitter è responsabile semplicemente di tempi di attesa differenti per i pacchetti nel buffer: i pacchetti che arrivano in anticipo sperimentano tempi di attesa maggiori, quelli in ritardo inferiori. Il ritardo iniziale di riproduzione serve a spostare in avanti tutte le deadline di riproduzione e ad assorbire, di fatto, il jitter. Ovviamente, ritardi iniziali eccessivi sono mal tollerati dall utente che abbia richiesto la riproduzione; i limiti consentiti variano a seconda del tipo di applicazione, ma in generale il ritardo al di sopra del quale un utente percepisce una cattiva qualità del servizio si aggira intorno ai 400 ms, anche se è meglio, perché riscontrato essere percettivamente tollerabile, se rimane attorno o sotto i ms. Per avere un idea dei ritardi medi e massimi in alcuni dei servizi di telefonia basti pensare osservare la tabella 5.1 Considerate queste tempistiche è obiettivo principale del progetto contenere al massimo i ritardi di bufferizzazione della voce ricevuta sul dispositivo mobile. Se si tiene 4 Il jitter si riferisce alla variazione statistica nel ritardo dei pacchetti, causata dalle code interne ai router congestionate. 106

117 5 Analisi e design architetturale Tabella 5.1. Tabella di confronto ritardi tra standard telefonici e applicativi VoIP Applicazioni e Standard Ritardi GSM 0,233 ms UMTS max 150 ms SimpleOPAL ms Skype ms, max 500 ms conto che i ritardi medi introdotti da SimpleOPAL si aggirano sui 150 ms e che il vincolo temporale complessivo è di 400 ms, si ha un margine di ritardo che può essere sfruttato per il buffering che arriva fino ad un massimo di 250 ms. Nel caso peggiore, cioè quello in cui SimpleOPAL tocca i massimi ritardi (250 ms) il vincolo per il buffering si abbassa a 150 ms. Si vedrà nel capitolo 6 come è stato rispettato questo vincolo temporale Vincoli per la connessione Bluetooth Considerato il fatto che si tratta di una comunicazione streaming e che i contenuti devono essere fruiti in tempo reale, conviene avere come supporto per la comunicazione un protocollo che abbia le caratteristiche di UDP 5. Come già visto nella trattazione del protocollo RFCOMM (paragrafo 4.2.3), esso ha un comportamento simile a TCP, mentre L2CAP viene generalmente scelto per canali su cui verrebbe usato UDP. Tuttavia L2CAP è un protocollo orientato alla connessione che invia in modo affidabile datagram con lunghezza massima fissa, ma che può essere personalizzato con configurazioni a diverso livello di affidabilità. Sebbene però Bluetooth permetta alle applicazioni di usare comunicazioni best-effort piuttosto che affidabili, si ha comunque un problema legato a L2CAP: adattare le semantiche di trasmissione per una connessione L2CAP verso un altro dispositivo va ad influire su tutte le restanti connessioni L2CAP, se presenti. Inoltre, poiché RFCOMM usa 5 UDP è un protocollo di trasporto a pacchetto best-effort, privo di connessione, ma in compenso molto rapido ed efficiente per le applicazioni time-sensitive. Viene infatti usato spesso per la trasmissione di informazioni audio o video, dato che le applicazioni in tempo reale richiedono un ritmo minimo di spedizione, non devono ritardare eccessivamente la trasmissione dei pacchetti e possono tollerare qualche perdita di dati. 107

118 5 Analisi e design architetturale L2CAP come livello di trasporto, anche le connessioni di questo tipo sono interessate. Sarebbe perciò uno svantaggio in quanto si andrebbe a disturbare altre applicazioni su quel dispositivo che hanno delle connessioni aperte. Per quanto riguarda invece gli aspetti di tipo pratico sulla ricerca dei dispositivi sono necessari alcuni accorgimenti per evitare malfunzionamenti causati da disturbi di collisione delle porte dei canali e per semplificare l utilizzo dell applicazione all utente. Dal momento che durante l uso dell applicazione BlueVoice altri servizi Bluetooth potrebbero essere presenti e attivi non solo sul dispositivo stesso, ma anche nelle immediate vicinanze, è indispensabile aprire dei socket e quindi instaurare delle connessioni su canali Bluetooth il cui numero di porta sia assegnato in modo dinamico piuttosto che scegliere staticamente tale numero in fase di progetto. Questa seconda possibilità causerebbe possibili collisioni con altre applicazioni server messe in ascolto sugli stessi canali e di conseguenza un malfunzionamento dell applicazione. L eventualità di collidere sui canali non è di fatto così remota in quanto il protocollo RFCOMM non ha a disposizione di un numero elevato di canali. Analogamente è opportuno che il server, sia quello presente sul PC che quello sul cellulare, presenti ad eventuali client il servizio di telefonia VoIP che è in grado di offrire. In questa maniera i client che ricercano il server BlueVoice scelgono e selezionano in modo intelligente solo i dispositivi o stazioni fisse con il particolare servizio che stanno cercando, discriminandoli da tutti gli altri host trovati. Sia la notifica delle porte che il servizio offerto vengono effettuati pubblicando le relative informazioni sul Service Discovery Protocol, già descritto nel paragrafo Aspetti di usabilità All interno di questa parte dedicata ai requisiti è doveroso elencare alcune questioni meno stringenti dei vincoli visti in precedenza che non vanno ad impattare tanto sul corretto funzionamento o meno dell applicazione, quanto sull usabilità finale percepita dal fruitore del software: 108

119 5 Analisi e design architetturale Il server ha il compito di dare all utente non solo gli avvisi tipici della telefonia (chiamata rifiutata, chiamata terminata, tempo della chiamata ecc.), ma lo deve informare ugualmente di anomalie di rete come caduta del link, codec non comuni, banda insufficiente, errori di trasporto, host non raggiungibile nella rete o host non in linea. Il sistema deve essere in grado di funzionare indipendentemente dalla modalità di utilizzo (Walkie-Talkie o telefonata VoIP) senza differenze di funzionalità, e l utente deve essere informato se il server a cui si è connesso è un altro telefono cellulare o un PC connesso ad Internet. Se l applicazione client dovesse essere terminata per carenza di batteria o semplicemente per un errore di digitazione dell utente, questi non deve ogni volta riavviare il server per ristabile una connessione. Il server deve essere perciò in modalità always-on e deve rilevare ogni caduta di connessione con il client, in modo da mettersi nuovamente in ascolto perché l utente possa ripristinare la connessione. Aggiunta di una entry nel registro delle chiamate per notificare al cliente la presenza di un chiamata non risposta. È preferibile utilizzare il log di sistema poiché l utente è maggiormente abituato a consultarlo e può reperire informazioni anche sulle chiamate provenienti dalla rete GSM o UMTS. 109

120 Capitolo 6 Implementazione del progetto 6.1 Introduzione La trattazione svolta in questo capitolo è la conseguenza degli obiettivi, vincoli e requisiti esposti in quello precedente in quanto ne descrive l implementazione pratica nell applicazione BlueVoice finale. È perciò rivolta ad un lettore che abbia una qualche dimestichezza con il sistema operativo Symbian e che abbia intenzione di affrontare uno studio del codice sviluppato con l eventuale intenzione di apportarne migliorie tecniche o aggiunte. Verranno infatti dettagliati con maggiore precisione tutti i componenti e le classi dei programmi server e client facenti parte dell applicazione, fornendone le caratteristiche funzionali viste nell ambito della struttura applicativa di cui si è fatto riferimento nei precedenti capitoli. 6.2 Architettura del progetto Classi client-side L applicazione BlueVoice eseguita sul telefono cellulare è stata realizzata utilizzando l IDE Carbide C++ ed è costituita da dodici classi, cinque delle quali rappresentano i 110

121 6 Implementazione del progetto componenti principali di un applicazione Symbian come visto nel capitolo 3 (paragrafo 3.4.2), mentre le rimanenti sono le classi che implementano specifiche funzioni come l instaurazione del canale Bluetooth o i passi per l acquisizione della voce. La figura 6.1 sintetizza graficamente la struttura implementativa di BlueVoice fornendone un chiaro diagramma UML che evidenzia per ogni classe le funzioni e gli attributi principali. Di seguito verrà fornito un dettagliato elenco delle classi implementate, ad esclusione delle classi BlueVoiceApp, BlueVoiceDocument e BlueVoiceView per la cui trattazione si rimanda al paragrafo in quanto non presentano particolari significativi al fine dell apprendimento dellle caratteristiche specifiche di BlueVoice. Classe BlueVoiceAppUi La classe eredita da CEikAppUi ed implementa le funzioni DynInitMenuPaneL e HandleCommandL. Quest ultima viene richiamata dal framework e serve per gestire i comandi forniti dall utente in forma di pressione dei tasti del tastierino del cellulare. In base alla scelta dei tasti o delle opzioni che le risorse dell applicazione mostrano in forma di menu o dialog, vengono richiamate opportune funzione per espletare i comandi richiesti. La funzione DynInitMenuPaneL inizializza dinamicamente il pannello del menu, ed è anch essa richiamata dal framework Uikon. In questo modo, sulla base dello stato e di valori relativi all applicazione, è possibile presentare all utente diverse opzioni del menu coerenti alla macchina a stati attraverso la quale passa il processo di chiamata; questo consiste nel nascondere o mostrare le opzioni, aggiungerne dinamicamente delle altre o modificarne i testi. Il costruttore della classe BlueVoiceAppUi istanzia ed inizializza anche oggetti di classe BlueVoiceEngine, VoiceInput, VoiceOutput e BlueVoiceView che verranno usati in seguito anche da altre classi, per le quali BlueVoiceAppUi fornisce un interfaccia di funzioni pubbliche che permettono di ottenere tali oggetti. Una funzione degna di nota è BringToForeground in quanto ha il compito di 111

122 6 Implementazione del progetto Figura 6.1. Diagramma UML dell applicazione BlueVoice riportare l applicazione che sta girando in background (per esempio se è in attesa di una chiamata) in primo piano, ovvero in foreground e quindi visibile all utente. È utilizzata per rendere visibile BlueVoice in modo che l utente possa consultare l elenco di eventuali 112

123 6 Implementazione del progetto chiamate perse. Classi VoiceInput e VoiceOutput Sono le classi preposte all acquisizione, alla trattazione e alla riproduzione del segnale vocale. Le operazioni di Input/Output della voce, cioè la fase di recording che dall apparato di fonazione umano all hardware del cellulare permette di salvare le informazioni registrate in pacchetti vocali dal formato digitale, e quella di playing che segue il percorso inverso dall altoparlante all orecchio e veicola all utente i pacchetti audio provenienti dalla connessione Bluetooth, sono interamente gestite nell ambito rispettivamente delle classi VoiceInput e VoiceOutput. La classe VoiceInput si occupa della registrazione vocale ed avvia il processo di Input audio mediante la funzione Record. Il compito espletato dalla funzione di registrazione risulta essere più semplice di quello per la riproduzione, in quanto non appena viene acquisito un frame vocale mediante la funzione CMdaAudioInputStream::ReadL, esso viene inviato sul canale Bluetooth richiamando le apposite primitive che la classe BlueVoiceEngine mette a disposizione. La classe VoiceInput implementa le funzioni definite nell interfaccia MMdaAudioInputStreamCallback, una classe di callback 1 che notifica il client sul processo di input streaming controllato grazie alla classe CMdaAudioInputStream. Queste funzioni sono: MaiscOpenComplete : indica l avvenuta apertura del buffer su cui sarà caricato il contenuto multimediale registrato dal microfono, consente di svolgere operazioni antecedenti il processo di input come impostazioni del guadagno, della codifica e della priorità del flusso e da il via alla registrazione vera e propria. MaiscBufferCopied : notifica che un frame audio è stato copiato nel buffer (a seguito dell avvenuta registrazione), che viene passato come riferimento nei parametri della funzione. Esso viene inviato all host remoto mediante la SendFrame 1 Le clasi di callback forniscono funzioni richiamate dal framework per avvertire dell avvenuto compimento di funzioni di sistema. 113

124 6 Implementazione del progetto del motore dell applicazione. Se non ci sono stati errori viene richiamata la funzione per acquisire il prossimo pacchetto di voce che richiamerà in modo ricorsivo questa funzione fino al termine della registrazione. MaiscRecordComplete : richiamata al termine della registrazione a seguito dell invocazione della funzione Stop. La classe VoiceOutput gestisce invece il buffer di playout 2 e si incarica di riprodurre i dati ricevuti. Analogamente alla classe per l input, essa implementa l interfaccia di callback MMdaAudioOutputStreamCallback la cui riscrittura dei metodi permette di aprire il buffer, copiare via via i frame nei registri hardware e terminare il processo, in un meccanismo del tutto simile a quello illustrato nell elenco precedente per la classe VoiceInput. I passi principali dell output streaming vengono effettuati dalla classe CMdaAudioOutputStream di cui le callback ne catturano i risultati e notificano gli effetti del processo al framework. In aggiunta tale classe si occupa di caricare i frame audio ricevuti in un buffer di playout secondo una procedura che verrà illustrata nel paragrafo In ultima analisi è utile ricordare che la frequenza di campionamento della voce è di 8 khz e che nella seconda edizione della Serie 60 la funzione ReadL della classe CMdaAudioInputStream restituisce i dati in frame da 320 byte. Sapendo che vengono prodotti campioni PCM di 16 bit è semplice calcolare la durata di ogni frame audio. Per fare ciò si calcola la velocità di campionamento: v c = f c N byte /campione = 16 kb/s (6.1) E quindi il tempo di durata del frame risulta essere: T frame = N byte/frame v c = 20 ms (6.2) Dove 2 Vedi

125 6 Implementazione del progetto f c = frequenza di campionamento [Hz] Questo calcolo è particolarmente utile nel conteggio del ritardo introdotto dal buffer di playout per contrastare gli effetti del jitter. Infatti, più frame vengono memorizzati prima della riproduzione, maggiormente viene contenuto questo problema, ma altresì aumentano i ritardi end-to-end a scapito della qualità e dell interazione della comunicazione. Se, d altro canto, si vuole ridurre il ritardo complessivo si rischia di non avere pacchetti nel buffer (a causa di un eccessivo ritardo di questi) quando essi sono necessari. Bisogna perciò trovare un giusto compromesso tra questi due aspetti. In definitiva si può affermare che le classi VoiceInput e VoiceOutput sono classi appartenenti al componente Modello del paradigma MVC, e cioè sono classi di tipo Engine. Il motivo per cui sono separate dall altra classe del Modello BlueVoiceEngine è per disaccoppiare gli algoritmi dedicati al trattamento audio da quelli per la gestione della connessione Bluetooth e della telefonata. Questa scelta è stata adottata in quanto è possibile modificare o rimuovere separatamente una delle due parti senza intaccare l altra, il che semplifica lo sviluppo e aumenta la flessibilità dell applicazione. Sono stati inoltre separati processi di registrazione e riproduzione perché in questo modo è possibile svolgere queste due operazione in contemporanea, garantendo così la funzionalità di full-duplex prescritta negli obiettivi. Classe BlueVoiceEngine La classe BlueVoiceEngine è sicuramente una delle classi principali del progetto in quanto coordina tutta la procedura di inquiry e di connessione Bluetooth, controlla la trasmissione e ricezione dei dati delegando le classi VoiceInput e VoiceOutput per il corretto utilizzo dei dati multimediali e gestisce le informazione di segnalazione necessarie per l instaurazione, la conservazione e l abbattimento della chiamata telefonica. Nel costruttore vengono istanziati due oggetti della classe Listener per i due socket 115

126 6 Implementazione del progetto Bluetooth ai capi dei due canali da e per l altro end-point, e tre oggetti rispettivamente delle classi DeviceDiscoverer, ServiceAdvertiser e ServiceDiscoverer. L utente può scegliere se fare comportare il proprio cellulare come client o come slave/server premendo rispettivamente i comandi Discover Devices oppure Start Slave. Nel primo caso viene lanciata la funzione DiscoverDevicesL della classe Engine, nel secondo StartSlaveL. Quest ultima ottiene due porte per i due canali mediante il metodo StartListenerL richiamato su due distinti oggetti della classe Listener e usa la classe ServiceAdvertiser per pubblicare queste informazioni sul database distribuito mediante il protocollo SDP. A questo punto il telefono è un server Bluetooth posto in attesa di eventuali connessioni. La funzione DiscoverDevicesL demanda invece i servizi di ricerca dispositivi alla classe DeviceDiscoverer e al completamento dell inquiry viene fornita all Engine la lista dei dispositivi trovati nel raggio d azione mediante la funzione di callback HandleDeviceDiscoveryCompleteL. Essa si occuperà inoltre di valutare se tra gli host reperiti ve n è qualcuno che fornisce il servizio BlueVoice mediante la funzione DiscoverServicesL che sfrutta a tale scopo le potenzialità offerte dalla classe ServiceDiscoverer e in caso affermativo viene attuata la connessione vera e propria grazie alla funzione ConnectDevicesL. Per fare ciò sono utilizzate due istanze delle classi Connector, e al termine si invoca la funzione ShowConnectedDevicesL per mostrare all utente il nome dell end-point a cui è connesso. Ciò che è stato presentato or ora a parole per le ricerca dei dispositivi è meglio illustrato nel diagramma di figura 6.2. Stabilita la connessione, l Engine coordina anche l invio e la ricezione di dati attraverso i canali Bluetooth mediante la SendFrame e una serie di funzioni di callback tra cui basti citare le due sfruttate per la ricezione pacchetti da parte dello slave e del master: HandleListenerDataReceivedL e HandleConnectorDataReceivedL. Esse si appoggiano entrambe alla funzione helper DataReceivedL che smista il traffico voce da quello di controllo per la segnalazione e rende totalmente identico e paritetico il ruolo di master e slave. Bisogna ricordare inoltre che BlueVoiceEngine eredita da CActive, la classe 116

127 6 Implementazione del progetto Figura 6.2. Diagramma UML della pubblicazione servizi a lato server e ricerca e connessione di dispositivi Bluetooth a lato client base per l astrazione di un active object, ed implementa infatti la funzione RunL per gestire i vari casi del completamento di una richiesta asincrona. Questa viene usata in tutti 117

128 6 Implementazione del progetto quei casi in cui all utente viene mostrato un dialog che lo interroga su determinate questioni (ad esempio se rispondere o meno ad una chiamata entrante) mentre uno o altri processi sono comunque in corso. La scelta dell utente causerà diversi comportamenti controllati e gestiti opportunamente. Si considerino a tale proposito tutte le funzioni di gestione della chiamata che hanno la duplice funzione di fare evolvere lo stato della telefonata e, al tempo stesso, notificare visivamente tale stato. Queste primitive per la chiamata sono: StartCall : inizia la chiamata inviando un opportuno messaggio di segnalazione all altro cellulare o al PC e si mette in attesa di risposta dell host remoto. StopCall : termina la chiamata e informa l altro soggetto della comunicazione di tale scelta. Inoltre richiama la funzione CallDuration per calcolare il tempo trascorso durante la conversazione e visualizzare una nota informativa al riguardo. HandleControlMessageL : è richiamata dalla funzione DataReceivedL quando riconosce di aver ricevuto un informazione di controllo. In questo caso la passa a HandleControlMessageL che si occupa di analizzarla e gestire le dovute operazioni. ReceiveCallData : anch esso è invocato da DataReceivedL nel caso duale in cui ciò che riceve è un pacchetto di voce. La ReceiveCallData coordina la riproduzione del segnale passando i pacchetti alla classe VoiceOutput. Quando entrambi gli host sono intenzionati ad instaurare una comunicazione telefonica tra loro, e cioè in seguito all accettazione del chiamato nei confronti del chiamante, su entrambi i dispositivi viene avviata la registrazione demandando, a tale scopo, le risorse offerte dalla classe VoiceInput che immediatamente invia all host remoto i dati acquisiti e che verranno gestiti, come visto, dalla funzione ReceiveCallData. Questa classe si occupa anche di aggiungere le entry nel registro delle chiamate perse in un processo che viene spiegato nel paragrafo

129 6 Implementazione del progetto Classe DeviceDiscoverer Questo componente è piuttosto semplice e si occupa della scansione wireless alla ricerca di dispositivi Bluetooth presenti all interno del raggio d azione. La funzione principale della classe è infatti DiscoverDevicesL che opera la fase di inquiry usando la classe Symbian RHostResolver, un interfaccia per servizi di risoluzione nomi, simile a DNS, che può essere usata con diversi protocolli. Ad esso viene infatti passato il nome del protocollo e l Inquiry Access Code (vedi 4.2.2) e si avvia il processo asincrono che, dati gli indirizzi, si occupa della risoluzione dei nomi degli host. Ad ogni dispositivo trovato vengono aggiornati i campi relativi al nome e indirizzo della struct TDeviceData che incapsula le informazioni di ogni apparecchio reperito ed è definita nel file header Common.h del progetto BlueVoice(vedi figura 6.3). La funzione di inquiry è chiamata da BlueVoiceEngine e ad essa viene passato il riferimento ad una lista di tipo TDeviceData, che in caso di dispositivi trovati, viene riempita con le informazioni di tutti gli host. Classi ServiceAdvertiser e ServiceDiscoverer Le classi ServiceAdvertiser e ServiceDiscoverer forniscono un servizio duale: la prima accede al database SDP per aggiungere un record che, quando il terminale mobile agisce da server, informa eventuali client del servizio offerto e di attributi utili per effettuare la connessione, la seconda invece è usata in modalità client per esaminare se tra tutti i dispositivi Bluetooth elencati nella lista di TDeviceData ve n è qualcuno che fornisce il servizio BlueVoice. È facile intuire come queste due classi vengano utilizzate in modo esclusivo a seconda della modalità in cui il terminale mobile sta operando: se esso è server della comunicazione avrà bisogno di comunicare i servizi disponibili per potersi mettere in ascolto e userà a tale scopo ServiceAdvertiser; analogamente se il telefono è client si troverà nella necessità di ricercare il server BlueVoice fra tutti i dispositivi Bluetooth trovati e utilizzerà ServiceDiscoverer. La funzione più di rilievo di ServiceAdvertiser è StartAdvertiserL che 119

130 6 Implementazione del progetto crea un service record e in esso scrive il valore delle porte che terminano i canali di ricezione dal client (achannelms) e quello di invio al client (achannelsm), oltre che ovviamente il tipo della modalità. Quest ultimo è definito da un valore intero che può assumere i valori 0 e 1; nel primo caso il server che pubblica questo service record è un PC con una connessione Internet, nel secondo caso è un cellulare che sta funzionando da server. Nella presente classe il tipo è perciò staticamente settato a 1. La classe ServiceDiscoverer presenta la funzione DiscoverServicesL la quale, in base alla lista fornita da DeviceDiscoverer, scandisce ogni singolo host per vedere se è del tipo cercato in base al identificativo unico del servizio pubblicato dal server che nel caso di BlueVoice assume il valore 0x10ff. Mediante la visita del record e dei suoi attributi vengono riempiti i campi della struttura TDeviceData rimanenti, cioè non ancora caricati nella fase di inquiry. La figura 6.3 mostra la struct che definisce l host remoto. Figura 6.3. Rappresentazione grafica della struct TDeviceData che definisce un dispositivo remoto Classi Listener e Connector La classe Listener è una particolarizzazione di CActive in quanto ha bisogno di gestire i socket Bluetooth ai capi dei canali instaurati con l altro end-point, ed è usata nella modalità server del terminale mobile. È quindi una sorta di thread che costantemente 120

131 6 Implementazione del progetto ascolta la porta in attesa di pacchetti in arrivo, e gestisce ogni evento asincrono richiamando la funzione RunL che in base allo stato in cui si trova la comunicazione svolgerà determinate operazioni e completerà le richieste dei client. La funzione che si occupa di inizializzare il server e di metterlo in condizione di ascoltare le richieste di connessione è StartListenerL che apre un socket sul protocollo RFCOMM destinato ad accogliere richieste di connessione, ottiene la porta per il canale di ascolto e lo pone in fase di attesa mediante la funzione RSocket::Listen(). Essa crea una coda per conservare le richieste che verranno poi accoppiate usando la Accept ad un socket vuoto che gestisce la connessione vera e propria. Il socket è ora pronto per ricevere dati e ciò viene eseguito mediante la funzione ReceiveData che, non appena ricevuto un pacchetto richiama HandleListenerDataReceivedL per avvertire l Engine dell arrivo dei dati, e si rimette in ascolto del dato successivo. Analogamente è possibile inviare dei dati sul socket grazie alla funzione SendDataL a cui l Engine passa opportunamente il pacchetto da inoltrare sul canale, quando se ne presenta l occasione. Così come i due oggetti Listener istanziati da BlueVoiceEngine rappresentano l astrazione dei due canali Bluetooth e ne gestiscono l evoluzione in due active object separati quando il terminale agisce da server, così la classe Connector controlla i socket della comunicazione nel caso in cui il cellulare ricerca un server e, trovato il servizio BlueVoice, usa due oggetti di tale classe per effettuare la connessione. Per fare ciò viene utilizzata la funzione ConnectL a cui sono passati i parametri rappresentanti l oggetto remoto (nome, indirizzo e porta) e una volta connessi i due oggetti (uno per canale di trasmissione) essi si comportano come visto per la classe Listener disponendo delle funzioni WaitAndReceiveL e SendDataL per ricevere ed inviare dati Struttura server-side Il server BlueVoice è un programma C++ lanciato da riga di comando ed eseguito su una macchina Linux, ed è sostanzialmente una modifica di SimpleOPAL a cui sono state apportate modifiche per interfacciare tale software con il client presente sul terminale mobile. La struttura di SimpleOPAL è piuttosto semplice e verrà esposta brevemente 121

132 6 Implementazione del progetto nel paragrafo successivo, mentre una maggiore attenzione sarà rivolta ai dettagli aggiunti durante la realizzazione del progetto di tesi. Non è intenzione di questo testo dedicare troppa attenzione a SimpleOPAL e sono infatti tralasciati aspetti poco rilevanti quali, per esempio, la trattazione del segnale video. Breve descrizione di SimpleOPAL Per lanciare SimpleOPAL è necessario compilare la Portable Windows Library 3 (PWLib), le librerie del progetto OPAL e digitare simpleopal -l, in modo da potere effettuare e ricevere chiamate. SimpleOPAL si compone di un metodo Main che viene lanciato all avvio del processo. Esso mostra sullo standard output tutte le possibili opzioni disponibili, e in caso di parametri impostati da riga di comando li elabora mediante la funzione Initialise. A questo punto viene lanciata la funzione Main dell oggetto MyManager che eredita dalla classe OpalManager già discussa nel paragrafo Tale funzione interroga l utente relativamente ai comandi disponibili e li svolge mediante una serie di funzioni coadiuvate da altre di callback che avvertono l utente di eventi come l arrivo di una chiamata, l accettazione della richiesta o la terminazione della connessione da parte dell utente remoto. Alcuni dei comandi possibili sono: M : invia un messaggio di testo all utente remote C : si connette all host remoto di cui si fornisce la URI SIP S : visualizza le statistiche H : termina la chiamata Integrazione di SimpleOPAL con un server Bluetooth Per poter permettere il collegamento con il cellulare è necessario implementare un server BlueVoice che si interfacci con un dispositivo Bluetooth montato sul PC o eventualmente 3 PWLib è una classe di librerie originariamente progettata come metodo per produrre applicazioni in grado di essere eseguite sia in sistemi Microsoft Windows che Unix/X11, e su cui SimpleOPAL si appoggia. 122

133 6 Implementazione del progetto un adattatore USB. Per fare ciò sono state usate le librerie BlueZ secondo un meccanismo del tutto simile a quello seguito per realizzare il server sul telefono cellulare. All avvio della funzione Main infatti, è stato creato un thread principale rappresentato dalla funzione btmanager parallelo al normale funzionamento di SimpleOPAL che quindi non è stato alterato e può essere utilizzato normalmente. La gestione degli aspetti legati alla connessione Bluetooth è affidata ad un ciclo infinito (while(1)) all interno del quale sono creati altri due thread, ognuno per il controllo dei socket in ascolto di connessioni da parte di client BlueVoice. La scelta di un ciclo infinito è motivata dal fatto che il server Bluetooth deve essere un demone attivo per tutta la durata del programma, e ogni volta che rileva la perdita di connessione BlueVoice da parte di un client, deve rimettersi in ascolto su altre porte per consentire allo stesso client, o eventualmente ad altri, di poter ristabilire un collegamento tra le due parti. In questo modo si garantisce la persistenza del server, mentre il thread principale cesserà di esistere solo con la terminazione di SimpleOPAL. Una volta creati i due thread all interno di quello parallelo al processo principale, se ne pubblicano i numeri di porta dei canali in ascolto mediante il protocollo SDP, grazie alla funzione register_service che sfrutta le API BlueZ per creare un service record dagli opportuni parametri e pubblicarlo sul database. Il ciclo infinito risulterebbe, da quanto visto finora, in un interminabile creazione di thread e conseguentemente di apertura socket, se esso non fosse fermato su un semaforo mediante una wait; la signal che sblocca tale semaforo viene invocata ogni qual volta un client termina il processo BlueVoice sul terminale mobile, causando in questa maniera la reinizializzazione del server. I due thread lanciano, al momento della creazione, due funzioni simili denominate receivingbtsocket e sendingbtsocket. Entrambe queste funzioni allocano un socket Bluetooth RFCOMM e gli assegnano dinamicamente un indirizzo locale grazie alla dynamic_bind_rc che richiama la bind sul socket tante volte quante sono le porte disponibili con il protocollo RFCOMM, e per ognuna controlla il valore di ritorno iterando finché essa non si completa con successo. Di seguito i due thread vengono bloccati con la 123

134 6 Implementazione del progetto listen che mette i socket in ascolto di eventuali connessioni. Come suggerisce il nome, la receivingbtsocket controlla il socket in ricezione dal client e implementa, a tale scopo, un ciclo continuo che va a leggere i dati ricevuti sull interfaccia Bluetooth e ne interpreta il significato legato alle informazioni di controllo, richiamando opportunamente le primitive di SimpleOPAL che gestiscono i vari casi della telefonata. Per notificare il client dello stato della connessione e in generale per inviare dati al dispositivo mobile, viene invece usata la funzione del secondo thread, ovvero la sendingbtsocket. Il thread di ricezione tuttavia è normalmente in ascolto sul canale e l evento scatenante una reazione è l arrivo asincrono di un pacchetto di dati, mentre quello di invio dipende dallo stato della chiamata VoIP e necessita perciò di una sincronizzazione tra il thread in questione ed il processo principale di SimpleOPAL. Quest obiettivo è raggiunto mediante l utilizzo delle funzioni wait e signal che, rispettivamente, bloccano e rilasciano il thread su un particolare semaforo. Non appena il socket è connesso si blocca il thread sul semaforo e viene sbloccato ogni qual volta succede qualche evento da parte della rete Internet ed è necessario informare il client di tali eventi. Si sfrutta a questo scopo una dettagliata macchina a stati per inviare al dispositivo il giusto messaggio di controllo e bloccarsi nuovamente sul semaforo. È importante far notare che il server potrebbe potenzialmente soddisfare le richieste di più di un client, ma poiché solo un utente alla volta può effettuare una chiamata VoIP, il server BlueVoice smette di pubblicare il servizio dopo la prima connessione e riprende a fornirlo dopo la terminazione della sessione Bluetooth. 6.3 Analisi di una chiamata Una chiamata BlueVoice si dipana attraverso una serie di passi e usa diverse risorse e formalismi mirati a garantire la connessione di tutte le parti in gioco e ad assicurare un utilizzo semplice e funzionale del sistema. Le caratteristiche principali che permettono di raggiungere tali obiettivi sono elencati di seguito: 124

135 6 Implementazione del progetto 1. Inquiry e connessione Bluetooth 2. Streaming della voce 3. Protocollo di segnalazione 4. Gestione del registro delle chiamate Inquiry e connessione Bluetooth Rappresenta la fase propedeutica per stabilire un canale bidirezionale (di fatto costituito da due singoli canali unidirezionali) che collega il processo residente sulla macchina Linux a capo della gestione della chiamata VoIP e quello attivo come applicazione Symbian sullo smartphone rappresentante il vero punto terminale della chiamata. Una volta terminata questa fase è possibile usare l applicazione fino all abbattimento della connessione. Tutte le funzioni utilizzate per portare a compimento questo passo sono già state esaminate esaustivamente nel paragrafo e forniscono il supporto per attuare la: 1. Ricerca dei dispositivi o Inquiry 2. Ricerca del servizio BlueVoice tra i dispositivi trovati 3. Connessione del client con il server BlueVoice 4. Utilizzo dei canali Bluetooth per invio e ricezione dei dati La figura 6.4 sintetizza graficamente le fasi di advertising, discovery dei dispositivi e dei servizi e lo stato di connessione con i due canali Bluetooth unidirezionali. La figura rappresenta il sistema connesso con una stazione fissa, ma è del tutto analogo se la connessione fosse in modalità Walkie-Talkie. 125

136 6 Implementazione del progetto Figura 6.4. Fase 1: Ricerca dispositivi e servizi ; Fase 2: sistema connesso Streaming della voce La riproduzione e l acquisizione della voce che deve essere poi mandata in streaming sul canale Bluetooth e successivamente su Internet sono compiti esclusivi delle due classi VoiceOutput e VoiceInput. Esse permettono da una parte di registrare la voce dell utente rappresentando il segnale analogico in pacchetti dal formato digitale PCM che 126

137 6 Implementazione del progetto verranno mandati on the fly verso l altro dispositivo, e dall altra di mandare in riproduzione quelli ricevuti. Per potere garantire la funzionalità full-duplex le due operazioni devono essere svolte in parallelo, in modo che l utente possa parlare e contemporaneamente sentire il soggetto all altro capo della comunicazione. Buffer di playout e riproduzione Come è già stato ampiamente trattato in precedenza è necessario avere un buffer di playout a lato ricevitore per evitare problemi legati ai ritardi variabili che causerebbero situazioni in cui la cadenza temporale di riproduzione dei pacchetti audio non venga rispettata con inevitabili cadute della qualità. In questo progetto è stato risolto il problema implementando un buffer circolare che memorizza un certo numero di pacchetti voce ricevuti prima di poterne avviare la riproduzione. L algoritmo per la bufferizzazione è implementato nella funzione PlayData della classe VoiceOutput a cui viene passato il frame voce ricevuto dall interfaccia Bluetooth, sfruttando le funzioni LoadBuffer e GetFrame, la prima per inserire un pacchetto nel buffer, la seconda per ottenere i dati da inviare all hardware per la riproduzione vera e propria. Per capire meglio il meccanismo e le variabili in gioco si osservi la figura 6.5. Le variabili iloadpointer e iplaypointer, inizialmente impostate a 0, sono i puntatori alle celle di memoria del buffer di playout che indicano rispettivamente la prima cella libera che può essere riempita con un pacchetto in ingresso, e la cella già occupata da dei dati che sarà la prossima ad essere estratta per la riproduzione. L algoritmo stabilisce che ad ogni arrivo di un frame venga richiamata la funzione LoadBuffer che lo inserisce nel buffer nella posizione corretta (in base al puntatore iloadpointer incrementato ad ogni arrivo) e gestisce la circolarità del buffer azzerando il puntatore per la memorizzazione ogni qual volta esso giunge all ultima cella. Inoltre vengono effettuati due controlli: 1. Il buffer presenta una soglia interna denominata KPlayoutThreshold il cui superamento da parte del puntatore di memorizzazione iloadpointer causa l inizio della riproduzione dei pacchetti fino a quel momento caricati nel buffer. 127

138 6 Implementazione del progetto Figura 6.5. Rappresentazione logica del buffer circolare e relative caratteristiche 2. Se i due puntatori di caricamento e di riproduzione dovessero andare a coincidere, ci si troverebbe nella situazione in cui viene riprodotto ciò che è in fase di memorizzazione, con un inevitabile e comprensibile degrado della qualità. Bisogna aggiungere che questa eventualità, non è così remota poiché a causa di ritardi di trasmissione i puntatori possono avere degli shift notevoli e addirittura andare a coincidere. Per evitare questo inconveniente viene controllata ogni volta la posizione relativa dei due puntatori, e nel caso puntassero alla stessa area di memoria si provvede a spostare il puntatore iloadpointer di un certo numero di frame in avanti. La riproduzione è preceduta dall apertura del buffer, operazione che causa l invocazione della funzione di callback MaoscOpenComplete 4. In essa si imposta il volume e la priorità del flusso, si stabilisce il tipo di codifica e si richiama la funzione WriteL 4 Vedi

139 6 Implementazione del progetto che riproduce i dati e richiama la callback MaoscBufferCopied. In quest ultima invece si richiama ricorsivamente la WriteL che riceve i pacchetti dalla GetFrame e autoalimenta il processo di riproduzione poiché viene nuovamente invocata la funzione MaoscBufferCopied e così via. La riproduzione di un dato frame all interno del buffer è immediatamente seguita dalla sua cancellazione caricando al suo posto il frame izero che, come suggerisce il nome, è completamente nullo. In questo modo si evita di avere il buffer carico di informazioni vecchie, cioè già riprodotte, che potrebbero impattare negativamente sulla qualità percepita dall utente nel caso di mancata ricezione di pacchetti dall interfaccia Bluetooth in quanto, in questo caso, il puntatore iplaypointer, ciclando sul buffer di playout, causerebbe la riproduzione ripetuta degli ultimi frame ricevuti e non cancellati. Nella funzione MaoscBufferCopied viene inoltre incrementato il valore dell indice iplaypointer, che sarà azzerato in GetFrame una volta giunto al valore massimo coincidente con la dimensione del buffer. Il processo può essere visualizzato come mostrato in figura 6.6. Acquisizione voce Il processo di acquisizione voce è iniziato quando l utente avvia la chiamata e la sua voce viene registrata, e segue un processo del tutto simile a quello esaminato per la riproduzione dei pacchetti vocali. La funzione Record apre il buffer e al termine di ciò la callback MaiscOpenComplete imposta il guadagno e la codifica e chiama la ReadL che effettivamente imposta il microfono in modalità di acquisizione voce, passandogli il puntatore all area di memoria dove scrivere i campioni. Come nel caso precedente, al termine del riempimento del buffer questo viene passato alla callback MaiscBufferCopied che si occupa di inviarlo grazie alla funzione SendFrame dell Engine, e richiama la ReadL per registrare il successivo frame vocale e così via. 129

140 6 Implementazione del progetto Figura 6.6. Evoluzione temporale del buffer circolare Valutazioni Considerati i ritardi introdotti da SimpleOPAL illustrati nella tabella 5.1 si vede che nel caso peggiore il ritardo di playout non può superare i 150 ms se si vuole rimanere al di sotto di 400 ms di ritardo complessivo. Dalla formula si evince che ogni frame da 320 byte ha una durata di 20 ms e da ciò si deriva facilmente che non possono essere memorizzati più di 7 frame. Conservativamente si è scelto di allocare un buffer di 6 frame, il che permette di avere ritardi dovuti alla memorizzazione dei dati che variano da 20 a 100 ms. Infatti la posizione dei due puntatori all interno del buffer è variabile e la figura 6.7 mostra il buffer fisico nei due casi estremi. 130

Sistemi Operativi per Sistemi di Elaborazione Ubiqui

Sistemi Operativi per Sistemi di Elaborazione Ubiqui Griglie e Sistemi di Elaborazione Ubiqui Sistemi Operativi per Sistemi di Elaborazione Ubiqui Griglie e Sistemi Ubiqui - D. Talia - UNICAL 1 Sistemi Operativi per Ubiquitous Computing Palm OS Symbian OS

Dettagli

Programmazione J2ME. Lezione 1. Le MIDlet. Di Blasi Gianpiero - D.M.I. - Università di Catania

Programmazione J2ME. Lezione 1. Le MIDlet. Di Blasi Gianpiero - D.M.I. - Università di Catania Di Blasi Gianpiero - D.M.I. - Università di Catania Programmazione J2ME Lezione 1 Le MIDlet Cosa impareremo oggi? Cosa è J2ME I profili MIDP ed i livelli di configurazione Il sistema di sicurezza di J2ME

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

J2ME Platform. Symbian OS. Nokia property platform: Series 60. Microsoft Windows CE.NET Microsoft Windows Mobile Mobile client-server communication

J2ME Platform. Symbian OS. Nokia property platform: Series 60. Microsoft Windows CE.NET Microsoft Windows Mobile Mobile client-server communication Dott. Giovanni Perbellini giovanni.perbellini@univr.it J2ME Platform J2ME Wireless Toolkit (WTK 2.2) Symbian OS Symbian SDK Nokia property platform: Series 60 Nokia Developer s Suite SDK Microsoft Windows

Dettagli

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006 tesi di laurea Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Anno Accademico 2005/2006 relatore Ch.mo prof. Stefano Russo correlatore Ing. Massimo Ficco candidato Giorgio

Dettagli

CAPITOLO 5 - Sistemi Operativi Moderni

CAPITOLO 5 - Sistemi Operativi Moderni CAPITOLO 5 - Sistemi Operativi Moderni PRESENTAZIONE DI INSIEME Vedremo ora come si è evoluta nel tempo la struttura di un sistema operativo, per passare dalle vecchie strutture di tipo normalmente modulari,

Dettagli

Termini che è necessario capire:

Termini che è necessario capire: Per iniziare 1........................................ Termini che è necessario capire: Hardware Software Information Technology (IT) Mainframe Laptop computer Unità centrale di elaborazione (CPU) Hard

Dettagli

Sistemi Operativi per Sistemi di Elaborazione Ubiqui

Sistemi Operativi per Sistemi di Elaborazione Ubiqui Griglie e Sistemi di Elaborazione Ubiqui Sistemi Operativi per Sistemi di Elaborazione Ubiqui Griglie e Sistemi Ubiqui - D. Talia - UNICAL 1 Sistemi Operativi per Ubiquitous Computing Palm OS SymbianOS

Dettagli

Programmazione ad Oggetti. Java Parte I

Programmazione ad Oggetti. Java Parte I Programmazione ad Oggetti Java Parte I Overview Caratteristiche generali 1 Caratteristiche generali Un moderno linguaggio orientato agli oggetti Pensato per lo sviluppo di applicazioni che devono essere

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

Lezione 4 La Struttura dei Sistemi Operativi. Introduzione

Lezione 4 La Struttura dei Sistemi Operativi. Introduzione Lezione 4 La Struttura dei Sistemi Operativi Introduzione Funzionamento di un SO La Struttura di un SO Sistemi Operativi con Struttura Monolitica Progettazione a Livelli di un SO 4.2 1 Introduzione (cont.)

Dettagli

Java per Sistemi Mobili e Ubiqui

Java per Sistemi Mobili e Ubiqui Griglie e Sistemi di Elaborazione Ubiqui Java per Sistemi Mobili e Ubiqui Griglie e Sistemi Ubiqui - D. Talia - UNICAL 1 Java per Ubiquitous Computing Java Micro Edition Real-time Java KVM Waba J9 JavaPhone

Dettagli

Corso di Sistemi Operativi DEE - Politecnico di Bari. Windows vs LINUX. G. Piscitelli - M. Ruta. 1 di 20 Windows vs LINUX

Corso di Sistemi Operativi DEE - Politecnico di Bari. Windows vs LINUX. G. Piscitelli - M. Ruta. 1 di 20 Windows vs LINUX Windows vs LINUX 1 di 20 Windows vs LINUX In che termini ha senso un confronto? Un O.S. è condizionato dall architettura su cui gira Un O.S. è condizionato dalle applicazioni Difficile effettuare un rapporto

Dettagli

Calcolo numerico e programmazione. Sistemi operativi

Calcolo numerico e programmazione. Sistemi operativi Calcolo numerico e programmazione Sistemi operativi Tullio Facchinetti 25 maggio 2012 13:47 http://robot.unipv.it/toolleeo Sistemi operativi insieme di programmi che rendono

Dettagli

1.3 Concetti base dell Informatica: Elaboratore

1.3 Concetti base dell Informatica: Elaboratore 1.3 Concetti base dell Informatica: Elaboratore Insegnamento di Informatica Elisabetta Ronchieri Corso di Laurea di Economia, Universitá di Ferrara I semestre, anno 2014-2015 Elisabetta Ronchieri (Universitá)

Dettagli

Architettura di un sistema operativo

Architettura di un sistema operativo Architettura di un sistema operativo Struttura di un S.O. Sistemi monolitici Sistemi a struttura semplice Sistemi a livelli Virtual Machine Sistemi basati su kernel Sistemi con microkernel Sistemi con

Dettagli

Music Everywhere with BT

Music Everywhere with BT Music Everywhere with BT Acquaviva Luca 231767 luca.acquaviva@studio.unibo.it Colombini Gabriele 231491 gabriele.colombini@studio.unibo.it Manservisi Alberto 258370 alberto.manservisi@studio.unibo.it Abstract

Dettagli

Strutture dei Sistemi Operativi

Strutture dei Sistemi Operativi Strutture dei Sistemi Operativi Componenti di sistema Servizi del sistema operativo Chiamate di sistema Programmi di sistema Struttura del sistema Macchine virtuali Progetto e implementazione di sistemi

Dettagli

Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010

Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010 Soft Control facile con RTX e Windows Embedded Standard 7 RTX 2009: funzionalità ed uso pratico Gianluigi Magnasco easitec S.r.l. Parma, 16 Settembre 2010 Definizione di Sistema Tempo Reale: Definizione

Dettagli

Sistemi Mobili e Wireless Android Introduzione alla piattaforma

Sistemi Mobili e Wireless Android Introduzione alla piattaforma Sistemi Mobili e Wireless Android Introduzione alla piattaforma Stefano Burigat Dipartimento di Matematica e Informatica Università di Udine www.dimi.uniud.it/burigat stefano.burigat@uniud.it Cos'è Android?

Dettagli

Sviluppo di applicazioni mobili su piattaforma Maemo

Sviluppo di applicazioni mobili su piattaforma Maemo tesi di laurea Anno Accademico 2009/2010 relatore Ch.mo prof. Marcello Cinque candidato Giovanni Fortini Matr. 534/2169 Contesto e contributo Sistemi operativi per dispositivi mobili Sviluppo di un applicazione

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia

Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia Introduzione: 1. Principi di base dei sistemi operativi 2. Sistemi

Dettagli

Centro Servizi e Sala Controllo

Centro Servizi e Sala Controllo Progetto SNIFF (Sensor Network Infrastructure For Factors) INFRASTRUTTURA DI SENSORI PER IL RILEVAMENTO DI INQUINANTI NELL ARIA PON RC1 [PON01_02422] Settore Ambiente e Sicurezza Comune di Crotone 1 Napoli,

Dettagli

LE RETI DI COMUNICAZIONE

LE RETI DI COMUNICAZIONE LE RETI DI COMUNICAZIONE (Prima parte) Settembre 2002 I diritti di riproduzione, di memorizzazione elettronica e di adattamento totale o parziale con qualsiasi mezzo, compresi i microfilm e le copie fotostatiche

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Parte VI SISTEMI OPERATIVI

Parte VI SISTEMI OPERATIVI Parte VI SISTEMI OPERATIVI Sistema Operativo Ogni computer ha un sistema operativo necessario per eseguire gli altri programmi Il sistema operativo, fra l altro, è responsabile di riconoscere i comandi

Dettagli

ANDROID. Domenico Talia. Università della Calabria. talia@dimes.unical.it

ANDROID. Domenico Talia. Università della Calabria. talia@dimes.unical.it ANDROID Domenico Talia Università della Calabria talia@dimes.unical.it Sistemi Operativi per Mobile! I sistemi operativi per sistemi mobili seguono i principi dei SO classici ma devono gestire risorse

Dettagli

Personal Digital Evidence. Contenuti. Dispositivi per la comunicazione I. Definizioni. Una introduzione alla. Mobile forensics

Personal Digital Evidence. Contenuti. Dispositivi per la comunicazione I. Definizioni. Una introduzione alla. Mobile forensics Personal Digital Evidence Una introduzione alla Mobile forensics Corso di Informatica Forense - OIG Facoltà di Giurisprudenza Università degli studi di Bologna Dr. Stefano Fratepietro m@il: stefano.fratepietro@unibo.it

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO SOMMARIO 1 Oggetto della Fornitura... 3 2 Composizione della Fornitura... 3 2.1 Piattaforma

Dettagli

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

Sistemi Operativi (modulo di Informatica II) Architettura

Sistemi Operativi (modulo di Informatica II) Architettura Sistemi Operativi (modulo di Informatica II) Architettura Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Obiettivi di un sistema operativo Concetti di base sui sistemi operativi

Dettagli

Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web

Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web Zoo di sistemi operativi: studio e realizzazione del supporto di macchine virtuali con accesso via Web Mattia Gentilini Relatore: Renzo Davoli Laurea Specialistica in Informatica I Sessione A.A. 2005/2006

Dettagli

corrispondente server Web (l applicazione server) viene inviata una richiesta, alla quale il server normalmente risponde inviando la pagina HTML che

corrispondente server Web (l applicazione server) viene inviata una richiesta, alla quale il server normalmente risponde inviando la pagina HTML che Prefazione In questo volume completiamo l esplorazione del linguaggio Java che abbiamo iniziato in Java Fondamenti di programmazione. I due testi fanno parte di un percorso didattico unitario, come testimoniano

Dettagli

Sistemi Operativi di Rete. Sistemi Operativi di rete. Sistemi Operativi di rete

Sistemi Operativi di Rete. Sistemi Operativi di rete. Sistemi Operativi di rete Sistemi Operativi di Rete Estensione dei Sistemi Operativi standard con servizi per la gestione di risorse in rete locale Risorse gestite: uno o più server di rete più stampanti di rete una o più reti

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

Approccio stratificato

Approccio stratificato Approccio stratificato Il sistema operativo è suddiviso in strati (livelli), ciascuno costruito sopra quelli inferiori. Il livello più basso (strato 0) è l hardware, il più alto (strato N) è l interfaccia

Dettagli

I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI

I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI Il Software Software di Base Sistema Operativo (Software di base essenziale) Software di base non essenziale Utility Driver Software applicativi (Applicazioni)

Dettagli

Corso: Informatica+ Andrea Cremonini. Lezione del 20/10/2014

Corso: Informatica+ Andrea Cremonini. Lezione del 20/10/2014 Corso: Informatica+ Andrea Cremonini Lezione del 20/10/2014 1 Cosa è un computer? Un elaboratore di dati e immagini Uno smartphone Il decoder di Sky Una console di gioco siamo circondati! andrea.cremon

Dettagli

Capitolo 1: Introduzione

Capitolo 1: Introduzione Capitolo 1: ntroduzione Che cos è un sistema operativo? Sistemi mainframe. Sistemi desktop. Sistemi multiprocessore. Sistemi distribuiti. Sistemi cluster. Sistemi in tempo reale. Sistemi palmari. Migrazione

Dettagli

JUG Sardegna Java Summer Meeting 16 Luglio 2005 1

JUG Sardegna Java Summer Meeting 16 Luglio 2005 1 JUG Sardegna Java Summer Meeting 16 Luglio 2005 1 J2ME Introduzione allo sviluppo di applicazioni per dispositivi mobili Stefano Sanna gerdavax@tiscali.it gerda@crs4.it JUG Sardegna Java Summer Meeting

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

1) Una periferica di input è: A) il mouse B) il monitor C) la stampante

1) Una periferica di input è: A) il mouse B) il monitor C) la stampante CONOSCENZE DI INFORMATICA 1) Una periferica di input è: A) il mouse B) il monitor C) la stampante 2) Una memoria in sola lettura con la particolarità di essere cancellata in particolari condizioni è detta:

Dettagli

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche Il Cloud Computing La visualizzazione nella Cloud Problematiche Virtualizzazione della GPU Front end Virtualization

Dettagli

DIMETRA IP Compact. una soluzione tetra completa e compatta

DIMETRA IP Compact. una soluzione tetra completa e compatta DIMETRA IP Compact una soluzione tetra completa e compatta MOTOROLA IL VOSTRO PARTNER TECNOLOGICO PRONTO E AFFIDABILE Un eredità straordinaria Le soluzioni TETRA di Motorola si avvalgono di oltre 75 anni

Dettagli

CLOUD COMPUTING. Che cos è il Cloud

CLOUD COMPUTING. Che cos è il Cloud CLOUD COMPUTING Che cos è il Cloud Durante la rivoluzione industriale, le imprese che si affacciavano per la prima volta alla produzione dovevano costruirsi in casa l energia che, generata da grandi macchine

Dettagli

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Funzioni e strategie di progettazione: dai kernel monolitici

Dettagli

03 L architettura del computer e la CPU (parte 2) Dott.ssa Ramona Congiu

03 L architettura del computer e la CPU (parte 2) Dott.ssa Ramona Congiu 03 L architettura del computer e la CPU (parte 2) Dott.ssa Ramona Congiu 1 Anatomia del computer Dott.ssa Ramona Congiu 2 L Unità centrale 3 Anatomia del computer 4 La scheda madre All interno del computer

Dettagli

Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base

Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base Sistema operativo Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base Architettura a strati di un calcolatore

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

WEB SERVER EMBEDDED PER APPLICAZIONI DI DOMOTICA. Fig. 1 - Architettura di un web server embedded

WEB SERVER EMBEDDED PER APPLICAZIONI DI DOMOTICA. Fig. 1 - Architettura di un web server embedded WEB SERVER EMBEDDED PER APPLICAZIONI DI Cristian Randieri Per far fronte alle esigenze di sviluppatori che intendono gestire applicazioni professionali per la domotica e la home building automation sfruttando

Dettagli

Fondamenti di Informatica: Sistemi Operativi 1. Introduzione

Fondamenti di Informatica: Sistemi Operativi 1. Introduzione Introduzione Fondamenti di Informatica: Sistemi Operativi 1 Elaboratori necessitano di SOFTWARE SOFTWARE DI SISTEMA (SISTEMI OPERATIVI): fanno funzionare le varie componenti del computer e permettono all

Dettagli

ERP Commercio e Servizi

ERP Commercio e Servizi ERP Commercio e Servizi Sistema informativo: una scelta strategica In questi ultimi anni hanno avuto grande affermazione nel mercato mondiale i cosiddetti sistemi software ERP. Tali sistemi sono in grado

Dettagli

Regione Piemonte: prospettive per lo sviluppo di ecosistemi digitali di business

Regione Piemonte: prospettive per lo sviluppo di ecosistemi digitali di business Regione Piemonte: prospettive per lo sviluppo Abstract Il presente documento intende illustrare la strategia e l approccio adottati da CSP nell ambito del progetto DIADI 2000 (progetto 2003-2006), iniziativa

Dettagli

ISTVAS Ancona Introduzione ai sistemi operativi Tecnologie Informatiche

ISTVAS Ancona Introduzione ai sistemi operativi Tecnologie Informatiche ISTVAS Ancona Introduzione ai sistemi operativi Tecnologie Informatiche Sommario Definizione di S. O. Attività del S. O. Struttura del S. O. Il gestore dei processi: lo scheduler Sistemi Mono-Tasking e

Dettagli

Soluzione per la VIDEOCONFERENZA EW2

Soluzione per la VIDEOCONFERENZA EW2 Soluzione per la VIDEOCONFERENZA EW2 1.Descrizione della Soluzione La soluzione per la audio/videoconferenza EW2 proposta da Gruppo SIGLA consente di comunicare e collaborare a distanza, senza muoversi

Dettagli

Prefazione. Contenuti

Prefazione. Contenuti Prefazione Il sistema operativo costituisce uno dei componenti fondamentali di ogni sistema di elaborazione, in particolare è quello con cui l utente entra direttamente in contatto quando accede al sistema,

Dettagli

Automazione di Test di Sistemi Embedded. Sintesi

Automazione di Test di Sistemi Embedded. Sintesi UNIVERSITÀ DEGLI STUDI DI MILANO - BICOCCA Facoltà di Scienze Matematiche, Fisiche e Naturali Dipartimento di Informatica Sistemistica e Comunicazione Corso di Laurea Magistrale in Informatica Automazione

Dettagli

***** Il software IBM e semplice *****

***** Il software IBM e semplice ***** Il IBM e semplice ***** ***** Tutto quello che hai sempre voluto sapere sui prodotti IBM per qualificare i potenziali clienti, sensibilizzarli sulle nostre offerte e riuscire a convincerli. WebSphere IL

Dettagli

Il Centro Regionale Information Communication Technology CeRICT scrl. Dott. Sergio Betti Direttore Generale CeRICT

Il Centro Regionale Information Communication Technology CeRICT scrl. Dott. Sergio Betti Direttore Generale CeRICT Il Centro Regionale Information Communication Technology CeRICT scrl Dott. Sergio Betti Direttore Generale CeRICT Storia CeRICT Il CeRICT nato nel 2002 come Progetto per la realizzazione di un centro di

Dettagli

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA Obiettivo Richiamare quello che non si può non sapere Fare alcune precisazioni terminologiche IL COMPUTER La struttura, i componenti

Dettagli

CORSO DI LAUREA IN SCIENZE ERBORISTICHE E DEI PRODOTTI NUTRACEUTICI

CORSO DI LAUREA IN SCIENZE ERBORISTICHE E DEI PRODOTTI NUTRACEUTICI CORSO DI LAUREA IN SCIENZE ERBORISTICHE E DEI PRODOTTI NUTRACEUTICI Informatica con esercitazioni Prof. Onofrio Greco Modulo 1 Concetti di base dell ICT Modulo 2 Uso del Computer e Gestione dei File Modulo

Dettagli

Un approccio per sviluppare applicazioni di. E Democracy basato su ruoli per agenti mobili

Un approccio per sviluppare applicazioni di. E Democracy basato su ruoli per agenti mobili UNIVERSITÀ DEGLI STUDI DI MODENA E REGGIO EMILIA Facoltà di Ingegneria Sede di Modena Corso di Laurea in Ingegneria Informatica Un approccio per sviluppare applicazioni di E Democracy basato su ruoli per

Dettagli

1. Hard Real Time Linux (Laurea VO o specialistica)

1. Hard Real Time Linux (Laurea VO o specialistica) 20/9/06 Elenco Tesi Disponibili Applied Research & Technology Dept. La Società MBDA La MBDA Italia è un azienda leader nella realizzazione di sistemi di difesa che con i suoi prodotti è in grado di soddisfare

Dettagli

Sistemi Operativi. Conclusioni e nuove frontiere

Sistemi Operativi. Conclusioni e nuove frontiere Sistemi Operativi (modulo di Informatica II) Conclusioni e nuove frontiere Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Definizione di sistema operativo Evoluzione futura

Dettagli

INFORMATION TECNOLOGY. a cura di Alessandro Padovani padoale@email.it

INFORMATION TECNOLOGY. a cura di Alessandro Padovani padoale@email.it INFORMATION TECNOLOGY 2 a cura di Alessandro Padovani padoale@email.it LE MEMORIE - 1 MEMORIA CENTRALE (O PRINCIPALE) Da questa memoria l unità centrale estrae i dati che servono per eseguire i programmi

Dettagli

Corso di Applicazioni Telematiche

Corso di Applicazioni Telematiche Corso di Applicazioni Telematiche Lezione n.1 Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria Obiettivi del corso Supporti didattici Modalità d esame Panoramica

Dettagli

In genere i portatili possono essere differenziati, per tipologia e uso, in due grandi categorie:

In genere i portatili possono essere differenziati, per tipologia e uso, in due grandi categorie: Pagina 1 di 8 Piattaforme hardware Personal Computer In questa parte verranno elencate le più diffuse tipologie di piattaforme hardware, descrivendo per ciascuna esempi di utilizzo e modelli e suggerendo

Dettagli

Sicurezza dei sistemi SIP: analisi sperimentale di possibili attacchi e contromisure

Sicurezza dei sistemi SIP: analisi sperimentale di possibili attacchi e contromisure UNIVERSITÀ DEGLI STUDI DI PISA FACOLTÀ DI INGEGNERIA Corso di Laurea in INGEGNERIA DELLE TELECOMUNICAZIONI Tesi di Laurea Sicurezza dei sistemi SIP: analisi sperimentale di possibili attacchi e contromisure

Dettagli

Alcatel OmniVista 4760

Alcatel OmniVista 4760 Alcatel OmniVista 4760 La piattaforma di gestione aperta Una soluzione completa per la gestione di rete ARCHITETTURA APERTA Il tentativo di essere al passo con le innovazioni nel campo delle reti e delle

Dettagli

Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione. Facoltà di Ingegneria. Laurea Magistrale in Ingegneria Informatica

Università degli Studi Roma Tre Dipartimento di Informatica ed automazione. Facoltà di Ingegneria. Laurea Magistrale in Ingegneria Informatica Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione Facoltà di Ingegneria Laurea Magistrale in Ingegneria Informatica Tesi di Laurea Sistema informativo per la gestione dei processi

Dettagli

Piattaforme hardware Personal Computer

Piattaforme hardware Personal Computer Pagina 1 di 8 Piattaforme hardware Personal Computer In questa parte verranno elencate le più diffuse tipologie di piattaforme hardware, descrivendo per ciascuna esempi di utilizzo e modelli e suggerendo

Dettagli

Reti di calcolatori. Condivisione di risorse e comunicazione con gli altri utenti

Reti di calcolatori. Condivisione di risorse e comunicazione con gli altri utenti Reti di calcolatori Condivisione di risorse e comunicazione con gli altri utenti Reti di calcolatori Anni 70: calcolatori di grandi dimensioni, modello time-sharing, centri di calcolo Anni 80: reti di

Dettagli

DD 1050i. Terminale di pesatura Serie Diade. Touch screen, mille dati con un dito.

DD 1050i. Terminale di pesatura Serie Diade. Touch screen, mille dati con un dito. DD 1050i Terminale di pesatura Serie Diade Touch screen, mille dati con un dito. Terminale di pesatura Serie Diade DD 1050i DIADE in matematica indica la combinazione di due elementi per raggiungere l

Dettagli

Reti di computer. Agostino Lorenzi - Reti di computer - 2008

Reti di computer. Agostino Lorenzi - Reti di computer - 2008 Reti di computer Telematica : termine che evidenzia l integrazione tra tecnologie informatiche e tecnologie delle comunicazioni. Rete (network) : insieme di sistemi per l elaborazione delle informazioni

Dettagli

Modello del Computer. Componenti del Computer. Architettura di Von Neumann. Prof.ssa E. Gentile. a.a. 2011-2012

Modello del Computer. Componenti del Computer. Architettura di Von Neumann. Prof.ssa E. Gentile. a.a. 2011-2012 Corso di Laurea Magistrale in Scienze dell Informazione Editoriale, Pubblica e Sociale Modello del Computer Prof.ssa E. Gentile a.a. 2011-2012 Componenti del Computer Unità centrale di elaborazione Memoria

Dettagli

ECDL MODULO 1 Concetti di base della tecnologia dell informazione. Prof. Michele Barcellona

ECDL MODULO 1 Concetti di base della tecnologia dell informazione. Prof. Michele Barcellona ECDL MODULO 1 Concetti di base della tecnologia dell informazione Prof. Michele Barcellona Hardware Software e Information Technology Informatica INFOrmazione automatica La scienza che si propone di raccogliere,

Dettagli

Software che sovrintende al funzionamento del computer eseguendo compiti diversi:

Software che sovrintende al funzionamento del computer eseguendo compiti diversi: Sistema Operativo dispensa a cura di Alessandro Bellini Software che sovrintende al funzionamento del computer eseguendo compiti diversi: 1. Gestire interazione utente macchina 2. Fornire un interfaccia

Dettagli

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

Dettagli

Framework Rich Client Application

Framework Rich Client Application Framework Rich Client Application RELATORE: Paolo Giardiello Savona, 30 settembre 2010 Agenda La Sogei Le applicazioni client Sogei Le caratteristiche Le soluzioni possibili Java Web Start Eclipse La scelta:

Dettagli

Titolo: È gradita una competenza base in Matlab. Conoscenze linguistiche: padronanza della lingua inglese

Titolo: È gradita una competenza base in Matlab. Conoscenze linguistiche: padronanza della lingua inglese Titolo: Studio e sviluppo di applicazioni innovative basate su tecnologia di sensori indossabili Descrizione: Le body sensor networks (BSN) sono costituite da piccoli dispositivi che posti sul corpo umano

Dettagli

Virtualizzazione. Orazio Battaglia

Virtualizzazione. Orazio Battaglia Virtualizzazione Orazio Battaglia Definizione di virtualizzazione In informatica il termine virtualizzazione si riferisce alla possibilità di astrarre le componenti hardware, cioè fisiche, degli elaboratori

Dettagli

TECNICO SUPERIORE PER I SISTEMI E LE TECNOLOGIE INFORMATICHE

TECNICO SUPERIORE PER I SISTEMI E LE TECNOLOGIE INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER I SISTEMI E LE TECNOLOGIE INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

UNIVERSITA DEGLI STUDI DI L AQUILAL FACOLTA DI INGEGNERIA Applicazioni per dispositivi mobili: gli strumenti di sviluppo di Flash Lite. Diego Vasarelli Indice degli argomenti trattati. Introduzione agli

Dettagli

uomo Software (sistema operativo) hardware

uomo Software (sistema operativo) hardware uomo Software (sistema operativo) hardware 1 Sistema operativo Insieme di programmi che svolgono funzioni essenziali per l uso del sistema di elaborazione Questi programmi sono i primi ad essere eseguiti

Dettagli

Con questo termine si individuano tutti i componenti fisici dei sistemi informatici. Tutto quello che si può toccare è hardware.

Con questo termine si individuano tutti i componenti fisici dei sistemi informatici. Tutto quello che si può toccare è hardware. 2008-10-28 - pagina 1 di 7 Informatica (Informazione Automatica) memorizzare elaborazione trasmissione (telematica) Complessità operazione testo audio immagini video realtà virtuale memorizzare 1 10 100

Dettagli

Sistemi embedded un dispositivo incapsulato progettato per una determinata applicazione

Sistemi embedded un dispositivo incapsulato progettato per una determinata applicazione Sistemi embedded esistono molte definizioni nessuna universalmente riconosciuta. In generale con sistema embedded si intende un dispositivo incapsulato all'interno del sistema da controllare progettato

Dettagli

Architettura di un sistema operativo

Architettura di un sistema operativo Architettura di un sistema operativo Dipartimento di Informatica Università di Verona, Italy Struttura di un S.O. Sistemi monolitici Sistemi a struttura semplice Sistemi a livelli Virtual Machine Sistemi

Dettagli

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro. Esercizio di GRUPPO: PROTOCOLLO INFORMATICO Mappa concettuale TECNOLOGIE DISPONIBILI Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Dettagli

Informatica 1. 6 Sistemi operativi e software. ing. Luigi Puzone

Informatica 1. 6 Sistemi operativi e software. ing. Luigi Puzone Informatica 1 6 Sistemi operativi e software ing. Luigi Puzone Windows caratteristiche principali: Windows è un Sistema Operativo Con Interfaccia Grafica Multiutente Multitasking Multithreading Multiprocessing

Dettagli

EUCIP IT Administrator - Modulo 2 Sistemi operativi Syllabus Versione 3.0

EUCIP IT Administrator - Modulo 2 Sistemi operativi Syllabus Versione 3.0 EUCIP IT Administrator - Modulo 2 Sistemi operativi Syllabus Versione 3.0 Copyright 2011 ECDL Foundation Tutti i diritti riservati. Questa pubblicazione non può essere riprodotta in alcuna forma se non

Dettagli

Capitolo 6. Wireless LAN: via i fili!

Capitolo 6. Wireless LAN: via i fili! Capitolo 6 Wireless LAN: via i fili! Spesso la realizzazione di una rete impone maggiori problemi nella realizzazione fisica che in quella progettuale: il passaggio dei cavi all interno di apposite guide

Dettagli

invisibile Bluetooth, la porta

invisibile Bluetooth, la porta Tecnologia Mobile Bluetooth, la porta invisibile L interfaccia Bluetooth, presente ormai in una gran parte dei moderni telefoni cellulari, permette di collegare numerose periferiche: ecco come funziona

Dettagli

Calcolatore: Elaborare: Input: Output: John von Neumann: Device: Embedded: Sistemi programmabili:

Calcolatore: Elaborare: Input: Output: John von Neumann: Device: Embedded: Sistemi programmabili: Autore: Maria Chiara Cavaliere Informatica di base Lezione 1 del 21/3/2016 Il corso di Informatica di base si baserà sulla spiegazione di tre moduli: -Architettura Hardware; -Sistema operativo; Parte teorica

Dettagli

Samsung SUR40: la tecnologia touch-screen che rivoluziona l interazione tra consumatore e brand

Samsung SUR40: la tecnologia touch-screen che rivoluziona l interazione tra consumatore e brand Samsung SUR40: la tecnologia touch-screen che rivoluziona l interazione tra consumatore e brand Perché Samsung SUR40 Display Surface Riconoscimento degli oggetti e delle mani Scoprite la vera differenza

Dettagli

Via F. Bulgherini 1 25020 FLERO (BS) Tel. 030/2563480 Fax. 030/2563470 Via Verdi, 70-20038 SEREGNO (MI) Tel. 0362/237874 P.IVA 03248470175 Cap. Soc.

Via F. Bulgherini 1 25020 FLERO (BS) Tel. 030/2563480 Fax. 030/2563470 Via Verdi, 70-20038 SEREGNO (MI) Tel. 0362/237874 P.IVA 03248470175 Cap. Soc. AS/400 STAMPANTI SERVER WINDOWS WORKSTATIONS MATERIALI DI CONSUMO SERVER LINUX CORSI DI FORMAZIONE CHI SIAMO Solution Line è una società di consulenza composta da professionisti di pluriennale esperienza,

Dettagli

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente:

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il.NET Framework By Dario Maggiari L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il cuore del.net Framework è costituito dal CLR (Common Language Runtime) che, secondo

Dettagli