Università degli Studi di Padova

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Università degli Studi di Padova"

Transcript

1 Università degli Studi di Padova Facoltà di Scienze MM.FF.NN. Laurea in Informatica MDTN: Mobile Delay Tolerant Network Un applicazione del principio del Delay Tolerant Networking in ambito mobile. Candidato: Stefano Bonetta Relatore: Claudio Enrico Palazzi Anno Accademico

2

3 Abstract L idea che ha portato alla realizzazione di questo progetto è stata quella di applicare il principio delle DTN (Delay Tolerant Network) in un contesto mobile allo scopo di realizzare un sistema in grado di fornire un servizio Internet pubblico e gratuito. Tale idea consiste nello sfruttare il principio di questa tipologia di reti applicandolo al contesto urbano composto dalle linee dei mezzi pubblici quali treni, autobus e tram al fine fornire uno specifico servizio ai viaggiatori. L obbiettivo è dunque quello di consentire agli utenti dotati di cellulari con supporto Wi-Fi di poter accedere a questo particolare servizio Internet gratuitamente e senza dover ricorrere all utilizzo di altre tipologie di connessioni a pagamento (es: UMTS, WAP). 3

4 4

5 Indice 1 Introduzione L idea Scopo dello stage DTN: Delay Tolerant Network Che cos è una DTN Funzionamento Packet switching vs Store-And-Forward Strategie di comunicazione Un nuovo livello: il Bundle Layer Bundle Protocol La piattaforma Android Panoramica generale L architettura Ciclo di vita di un applicazione Sviluppo Android SDK Integrazione con l ambiente di sviluppo Eclipse Resoconto dell attività di individuazione e analisi di un Framework per DTN La ricerca Bytewalla Funzionamento Architettura a layer Confronto con MDTN Analisi preliminare del codice e della documentazione Conclusione

6 INDICE 5 Analisi dei requisiti Funzionalità del prodotto Contesto d uso del prodotto Caratteristiche degli utenti Assunzioni e dipendenze Modalità Diagramma architetturale Use-case Use-case 1: Client DTN Use Case 2: Server DTN Lista dei requisti Requisiti obbligatori Requisiti desiderabili Requisiti opzionali Progettazione Premesse architetturali Componenti richieste Formato dei Bundle Definizione dei componenti Metodo e formalismo di specifica Architettura generale del sistema e identificazione dei componenti architetturali di alto livello Package source.mdtn.bundle Package source.mdtn.comm Package source.mdtn.android Package source.mdtn.server Package source.mdtn.util Particolarità del servizio Configurazione Configurazione hardware del server Avvio e configurazione del server MDTN Testing Dotazione e ambiente di lavoro Test delle singole componenti Collaudo

7 INDICE 9 Conclusioni Consuntivo Sviluppi futuri Possibilità d uso del prodotto Preventivo di installazione Considerazioni personali A Manuale del client MDTN 95 A.1 Installazione dell applicazione A.2 Utilizzo A.2.1 Schermata iniziale A.2.2 Connessione al servizio A.2.3 Invio di A.2.4 Richiesta e gestione delle risorse Glossario 103 Bibliografia 107 7

8 8 INDICE

9 Elenco delle figure 2.1 Esempio di una DTN interplanetaria. [3] Viaggio dell informazione in una comunicazione packet switching. [3] Esempio di comunicazione in una DTN. [3] Store-And-Forward Message Switching. [3] Esempio di Scheduled Communication. [3] Confronto tra l architettura a layer Internet e DTN [3] Evoluzione di un bundle. [3] Protocollo non conversazionale Android in esecuzione su un HTC Evo 4G Architettura della piattaforma Android. [4] ADT in esecuzione su Eclipse Diagramma architetturale di Bytewalla [5] Diagramma dell architettura a layer di Bytewalla [5] Diagramma architetturale di MDTN Diagramma dell architettura a layer di MDTN Diagramma architetturale del sistema Diagramma architetturale del sistema nello scenario esteso Use-case 1 - Client DTN Use-case 2 - Server DTN Primary Block Payload Block Diagramma dei package di MDTN Package source.mdtn.bundle Package source.mdtn.comm Package source.mdtn.android Package source.mdtn.server Package source.mdtn.util

10 ELENCO DELLE FIGURE 6.9 Invio di un tramite web-service Messaggio di errore durante avvio del server Schermata del server MDTN Confronto preventivo-consuntivo ore A.1 Installazione del client MDTN A.2 Schermata di avvio A.3 Nessun collegamento Wi-Fi A.4 Connessione al servizio A.5 Invio di un A.6 Notifica dell invio effettivo dell A.7 Schermata gestione files A.8 Richiesta di una nuova risorsa A.9 Fallimento di una richiesta: risorsa inesistente o troppo grande A.10 Sincronizzazione A.11 Download di una risorsa A.12 Avanzamento del download e completamento

11 Elenco delle tabelle 4.1 Confronto tra Bytewalla e MDTN Configurazione delle periferiche del server

12 12 ELENCO DELLE TABELLE

13 Capitolo 1 Introduzione In questo primo capitolo spiegheremo le motivazioni e gli scopi che hanno portato alla realizzazione di questo stage e introdurremo il concetto di DTN. Nel secondo capitolo verranno approfonditi quelli che sono i principi fondamentali delle reti DTN attraverso una serie di esempi pratici che ci permetteranno di capirne le potenzialità. Passeremo poi ad una panoramica sul funzionamento della piattaforma Android (capitolo 3) in cui ci occuperemo di descrivere le sue principali caratteristiche e particolarità fino ad arrivare ai capitoli 4,5,6 e 7 che saranno invece dedicati all analisi, progettazione e configurazione del sistema MDTN. Nel capitolo 8 verrà discussa l attività di testing e collaudo mentre l ultimo capitolo sarà dedicato alle conclusioni e alle considerazioni personali sullo stage e sui possibili sviluppi futuri. 1.1 L idea Le DTN sono particolari tipi di reti sviluppate negli anni sessanta per le comunicazioni spaziali che basano il loro funzionamento sul principio della tolleranza ai ritardi. All interno di queste reti non è infatti richiesta una connessione continua tra i vari nodi, che oltre ad essere i soggetti della comunicazione sono anche i veri e propri trasportatori fisici dei dati. Queste reti si caratterizzano quindi per possedere proprietà particolari che le differenziano dalle altre e le rendono particolarmente interessanti sotto svariati aspetti. Robustezza e capacità di adattamento all ambiente in cui si opera sono le caratteristiche che rendono tali reti tolleranti a condizioni ed eventi che normalmente impediscono qualsiasi tipo di comunicazione. Da 13

14 CAPITOLO 1. INTRODUZIONE qui l utilizzo principale delle DTN, storicamente nate per rendere possibili quelle che oggi chiamiamo comunicazioni satellitari ed extra-terrestri, che per la loro stessa natura sono caratterizzate da condizioni operative estreme. Abbassando il livello di complessità ed entrando nel piccolo della nostra vita quotidiana possiamo facilmente trovare degli scenari che, seppur in scala ridotta, sono caratterizzati da problemi simili. Basti pensare alle reti di telefonia mobile che ancora oggi non sono in grado di fornire una copertura totale e lasciano scoperte non poche aree del nostro paese (per la maggior parte in zone rurali, ma non solo). Oppure alle reti wireless cittadine, che sempre più stanno prendendo piede in un pò tutte le città del mondo e che devono scontrarsi con problemi logistici a volte insormontabili (come edifici, interferenze, ecc...). Per quanto riguarda quest ultimo punto la tecnologia ha già provveduto a fornire una soluzione (stiamo parlando del WiMAX) che teoricamente eliminerà gli attuali limiti dei servizi wireless. In attesa di poter effettivamente usufruire di questa nuova tecnologia, purtroppo vincolata dalle paradossali leggi del mercato, diverse persone tra cui ricercatori, studenti e interi gruppi di ricerca si sono dedicati alla ricerca di possibili soluzioni per riuscire a portare Internet li dove non c è utilizzando proprio i principi delle reti DTN. Ponendoci ad esempio nel contesto urbano-cittadino, già caratterizzato dalla presenza di numerose reti di trasporti, possiamo immaginare di andare ad utilizzare queste stesse reti come basamento per la realizzazione di un servizio Internet operante come una DTN. Supponiamo, ad esempio, che ogni mezzo pubblico (d ora in poi carrier) trasporti un computer fisso o un portatile con un access-point in grado di fornire un servizio wireless capace di raccogliere varie richieste provenienti degli utenti a bordo, i quali potrebbero richiedere un certo servizio o una certa risorsa reperibile su Internet tramite il loro dispositivo mobile. Il carrier non dispone di una connettività costante ad Internet, in quanto trattandosi di un autobus/tram/treno è in continuo movimento (si suppone comunque che la connettività sia presente nelle stazioni e/o nelle fermate), pertanto memorizza le richieste dei vari utenti in attesa di disporre della connettività e quindi di poterle soddisfare. Ogni volta che ottiene la connettività il carrier soddisfa quante più richieste possibile e mette a disposizione eventuali risorse ottenute agli utenti che le hanno richieste. Mentre sono a bordo gli utenti possono comunicare costantemente con il servizio del carrier attraverso il loro dispositivo mobile, controllando se le 14

15 1.2. SCOPO DELLO STAGE loro richieste sono state soddisfatte e se eventualmente sono disponibili delle nuove risorse da scaricare. In aggiunta, possiamo pensare che una risorsa richiesta da un utente possa essere di interesse comune (pensiamo alla prima pagina di un quotidiano). In questi casi la risorsa potrebbe essere resa pubblica per poter essere utilizzata da tutti gli utenti, magari pubblicandola su una sorta di bacheca virtuale. Gli utenti inoltre dovrebbero disporre giornalmente di una quantità limitata di dati che è possibile scaricare, che cambi a seconda delle capacità della connettività presente e delle caratteristiche prestazionali della macchina montata sul carrier che eroga il servizio. Gli stessi utenti dovrebbero poi potersi riunire in gruppi che, sommando le capacità dei singoli utenti, avrebbero a disposizione una banda più grande in grado di richiedere risorse più pesanti. In questo modo avremmo realizzato un particolare tipo di servizio Internet, caratterizzato dal comportamento e dai delay classici di una DTN. Da questo momento in poi ci riferiremo a quest idea e a questa struttura di rete con il termine MDTN: Mobile Delay Tolerant Network. 1.2 Scopo dello stage Lo scopo dello stage è stato quello di andare ad implementare realmente il sistema MDTN, ovvero di andare a realizzare le componenti necessarie al suo funzionamento. Data la vastità degli elementi da sviluppare sono stati individuati una serie di requisiti obbligatori e desiderabili ritenuti fondamentali per il funzionamento del sistema, mentre sono state definite come opzionali altre caratteristiche in quanto il monte ore disponibile non era tale da garantire con certezza la loro realizzazione (per un maggiore dettaglio si veda la sezione 5.8). L attività di stage ha portato alla realizzazione di due prodotti distinti: server MDTN: applicazione Java che gestisce la logica di funzionamento del servizio e che viene eseguita sul computer trasportato a bordo del carrier. Adottando i principi delle DTN, essa permette agli utenti a bordo di usufruire dei servizi di invio e di richiesta risorse. client MDTN: ovvero l applicazione utilizzabile dall utente, operante sulla piattaforma mobile Android, che permette ai passeggeri del carrier di interfacciarsi con il servizio MDTN e quindi di poter inviare e richiedere risorse attraverso il proprio smartphone. 15

16 CAPITOLO 1. INTRODUZIONE Il sistema risulta quindi composto da queste due applicazioni, la cui interazione costituisce di fatto il vero e proprio servizio MDTN. Un ulteriore scopo dello stage, non meno importante, è stato quello di individuare una configurazione di rete adatta alle esigenze del servizio stesso, a partire dai dispositivi hardware necessari fino alla loro configurazione (vedi capitolo 7). 16

17 Capitolo 2 DTN: Delay Tolerant Network In questo capitolo ci occuperemo di descrivere nel dettaglio il funzionamento delle DTN, analizzando le tecniche e le strategie di comunicazione comunemente utilizzate da tali reti. Attraverso una serie di esempi mirati e di confronti cercheremo di evidenziare quali sono le potenzialità e i vantaggi di queste reti rispetto alla comune rete Internet. 2.1 Che cos è una DTN La Delay Tolerant Network (o Disruption Tolerant Network) è un architettura di rete di telecomunicazione che, come suggerisce il nome, è caratterizzata da una particolare tolleranza ai ritardi di comunicazione e ai problemi derivanti dalla disgregazione della struttura della rete stessa. Le reti di questo tipo sono solitamente caratterizzate da ritardi di trasmissione lunghi e molto variabili, da periodi di perdita di connettività dalla durata arbitrariamente lunga e da una forte asimmetria di trasmissione di dati nelle due direzioni. Tali fattori fanno si che il tasso di errore in queste comunicazioni sia molto elevato e pertanto risultano necessari particolari strategie ed accorgimenti architetturali in grado di rendere possibili queste trasmissioni. Esempi classici di DTN sono le reti utilizzate dai sistemi di comunicazione extra-terrestri, come quelli che permettono alle postazioni terrestri di comunicare con sonde e satelliti nello spazio, o in generale consentono a quest ultimi di comunicare tra loro. In questo ambiente operativo, infatti, i normali protocolli usati per Internet non sono adatti a far fronte a condizioni estreme quali le distanze elevatissime, i ritardi di trasmissione, la perdita di potenza del segnale, l oscuramento di quest ultimo dovuto a 17

18 CAPITOLO 2. DTN: DELAY TOLERANT NETWORK interposizione di corpi celesti, gli elevati disturbi dovuti ai campi elettromagnetici planetari e alle radiazioni cosmiche. Da qui le ovvie necessità che hanno portato allo sviluppo delle DTN il cui campo di applicazione naturale è dunque, storicamente, quello dell esplorazione dello spazio e della realizzazione di reti di comunicazioni interplanetarie (Fig. 2.1). Non deve stupire che il principale promotore della ricerca in questo settore sia proprio la NASA, che contribuisce attivamente agli studi da diversi anni. Figura 2.1: Esempio di una DTN interplanetaria. [3] Più in generale lo scopo delle DTN è quello di far comunicare tra loro reti indipendenti ed eterogenee (tra cui anche Internet) che possono essere prive di connettività costante, creando una sorta di overlay in grado di interconnettere tra loro tali reti in modo da consentire lo scambio di 18

19 2.2. FUNZIONAMENTO informazioni e migliorando al tempo stesso anche la qualità e la portata delle comunicazioni. 2.2 Funzionamento Il funzionamento delle DTN, così come i principi che le governano, sono definiti all interno dei documenti di riferimento RFC 4838: Delay- Tolerant Networking Architecture[2] e RFC 5050: Bundle Protocol Specification[1] che definiscono rispettivamente le caratteristiche architetturali e la tipologia del protocollo di comunicazione. Ci serviremo proprio di questi documenti per descrivere, nelle pagine seguenti, i principali componenti e le tecniche utilizzate da queste reti Packet switching vs Store-And-Forward Il primo passo da fare è quello di capire perché le tecniche normalmente usate su Internet non vanno bene per realizzare una rete con le caratteristiche di una DTN. La rete Internet basa le sue trasmissioni sulla tecnica del cosiddetto packet switching. Tale tecnica prevede che i blocchi di informazioni da trasmettere vengano inizialmente scomposti in pacchetti, che vengono successivamente spediti dalla sorgente verso la destinazione seguendo percorsi indipendenti attraverso una rete di link interconnessi da routers. Tali pacchetti sono formati da una parte di payload (insieme di dati che costituiscono una porzione dell informazione contenuta nel blocco iniziale) e da una parte di header (contenente informazioni di controllo) e sono il risultato di una serie di incapsulamenti sequenziali che portano l informazione dal livello applicazione fino al livello fisico (Fig. 2.2). Nel passaggio da un livello all altro ogni layer si occupa di aggiungere o rimuovere i propri header (a seconda del fatto che si stia inviando o ricevendo dati) in modo da fornire al successivo le informazioni nel formato corretto. Ogni host (ovvero ogni nodo della rete che ricopre il ruolo di sorgente/destinazione di un messaggio) della rete Internet deve quindi implementare i seguenti protocol layers, nell ordine: Application Layer: Genera e/o utilizza le informazioni relative alla comunicazione (i messaggi); è il livello più vicino all utente. Transport Layer: Permette un trasferimento di dati trasparente e affidabile (implementando anche un controllo degli errori e delle perdite) tra due host. 19

20 CAPITOLO 2. DTN: DELAY TOLERANT NETWORK Figura 2.2: Viaggio dell informazione in una comunicazione packet switching. [3] È il primo livello realmente end-to-end, cioè da host sorgente a destinatario, ed utilizza il protocollo TCP. Network Layer: Rende i livelli superiori indipendenti dai meccanismi e dalle tecnologie di trasmissione usate per la connessione. Si occupa di stabilire, mantenere e terminare una connessione, garantendo il corretto e ottimale funzionamento della sotto-rete di comunicazione attraverso il routing e la gestione delle congestioni. Il protocollo usato è IP. Link Layer: Si occupa di isolare i livelli superiori dal livello fisico, facendolo apparire come una connessione esente da errori. Per fare ciò deve implementare il sistema di conferme (acknowledgement) e regolare il flusso di dati (flow control). A seconda della tipologia di nodo vengono utilizzati protocolli diversi (es: Ethernet all interno di reti LAN, PPP per le connessioni dial-up e ad alta velocità). Physical Layer: Trasmette un flusso di dati grezzi attraverso un collegamento fisico (cavo, fibra ottica,...). Si occupa di gestire l apparato tecnico, meccanico ed elettronico (hardware) necessario alla gestione di tale trasmissione. I nodi più semplici (come i routers) possono limitarsi ad implementare solamente gli ultimi tre livelli (Network, Link, Physical). Come abbiamo accennato prima ogni pacchetto può essere instradato su un percorso fisico differente, quindi potenzialmente ognuno di essi può impiegare un tempo diverso a raggiungere la destinazione o andare perso e non è quindi garantito l arrivo ordinato dei pacchetti (richiedendo così la presenza di un particolare meccanismo di riassemblamento, in grado di richiedere eventuali pacchetti mancanti e di inviare le conferme di avvenuta 20

21 2.2. FUNZIONAMENTO ricezione, i cosiddetti ack). Considerando il funzionamento del protocollo TCP possiamo notare come questo sia fondamentalmente un protocollo botta-e-risposta. Basti pensare alla sequenza di passi necessari ad inviare un messaggio, che comportano un alto numero di round-trips tra sorgente e destinazione: Setup: three-way handshake (3 round-trips). Transfer: invio di n segmenti TCP confermati da ack (n round-trips). Take-down: four-way hanshake (4 round-trips). Sulla base di quanto detto finora possiamo dire che il funzionamento di Internet si basa logicamente sulle seguenti assunzioni: Presenza continua di una connessione bidirezionale (un link) tra sorgente e destinazione ai fini di garantire la possibilità di interazione reciproca. Delay di comunicazione relativamente piccoli tra l invio dei pacchetti e la ricezione dei rispettivi ack. Relativa simmetria della trasmissione bidirezionale (in termini di data rate). Basso tasso di errori e di corruzione dei pacchetti. Risulta evidente come tali assunzioni contrastino con il contesto applicativo delle DTN, per le quali valgono altresì le seguenti assunzioni: Connettività intermittente, in quanto non è sempre presente una connessione end-to-end per effettuare la comunicazione. Delay di comunicazione lunghi e variabili. Possibilità di avere un alto tasso di asimmetria nella trasmissione. Alto tasso di errori. Tali assunzioni, riassunte molto bene nell esempio in Fig. 2.3, dimostrano la necessità di adottare un diverso approccio di comunicazione. Una delle tecniche in grado di adottare un diverso approccio è la cosiddetta tecnica dello Store-And-Forward Message Switching. 21

22 CAPITOLO 2. DTN: DELAY TOLERANT NETWORK Figura 2.3: Esempio di comunicazione in una DTN. [3] Lo Store-And-Forward Message Switching è un metodo che tutti noi conosciamo, in quanto viene usato dai sistemi postali e dai corrieri già da centinaia di anni, ed è lo stesso principio su cui si basa il funzionamento della posta elettronica! Questo metodo fa della semplicità il suo punto forte: ogni messaggio (sia esso un intero blocco di informazione o una sua parte) viene inoltrato a partire dall area di memorizzazione di un nodo fino ad arrivare all area di memorizzazione di un altro nodo (che eventualmente può essere il destinatario del messaggio), come illustrato in Fig Figura 2.4: Store-And-Forward Message Switching. [3] 22

23 2.2. FUNZIONAMENTO Queste aree di memorizzazione (storage place), realizzabili con un semplice hardisk, possono memorizzare per un tempo arbitrario il messaggio, garantendo la persistenza dell informazione. Sono quindi definibili come persistent storage place, in contrapposizione ai sistemi di memorizzazione usati nei nostri router che, essendo realizzati con chip di memoria, garantiscono un tempo di permanenza dei pacchetti (e quindi di persistenza) nell ordine dei millisecondi. I vantaggi derivanti dall avere questa persistenza sono diversi e motivano la necessità di dotare i router DTN di questi sistemi di persistent storage. Vediamo quindi quali sono le ragioni per le quali disporre dell informazione per un lungo periodo potrebbe rilevarsi fondamentale: Il collegamento al nodo successivo potrebbe non essere disponibile per un lungo periodo. Un nodo può inviare/ricevere dati più velocemente rispetto ad un altro. Un messaggio, una volta trasmesso, potrebbe richiedere di essere ritrasmesso a seguito di errori di trasferimento e/o inoltro nei nodi successivi. Attraverso l invio di interi messaggi attraverso singoli trasferimenti è inoltre possibile fornire un informazione immediata ai nodi della rete, i quali possono conoscere subito la dimensione del messaggio e di conseguenza regolarsi in base allo spazio di memorizzazione richiesto e alla banda necessaria per la ritrasmissione. In definitiva, RFC4838[2] prevede per le DTN un sistema di trasferimento basato sullo Store-And-Forward Message Switching Strategie di comunicazione Come abbiamo appena visto, nella rete Internet una connettività intermittente è causa di perdita di dati e può portare al fallimento della comunicazione. Nelle DTN, al contrario, le connessioni di questo tipo possono essere utilizzate mascherando i delay di trasmissione tramite tecniche di tipo store-and-forward. Più in generale, il problema della connettività intermittente tra i nodi può essere affrontato attraverso delle particolari strategie di comunicazione. Opportunistic Communication Questa strategia di comunicazione, letteralmente opportunistica, è esattamente quella che adottiamo tutti noi quando camminiamo per strada. Se 23

24 CAPITOLO 2. DTN: DELAY TOLERANT NETWORK ci capita di incontrare un nostro amico innanzitutto lo salutiamo, e se abbiamo qualcosa da dirgli allora ci fermiamo a parlare e infine riprendiamo a camminare nella direzione in cui stavamo procedendo prima di fermarci. Questo comportamento è facilmente applicabile a svariati contesti: persone, automobili, aerei, satelliti possono comunicare e scambiarsi informazioni ogni volta che sono opportunamente allineati e/o abbastanza vicini da poter instaurare una comunicazione, senza alcuna previsione. Scheduled Communication In alternativa, quando la comunicazione opportunistica non risulta efficiente è possibile sfruttare dell informazione pregressa ai fini di programmare nel tempo le trasmissioni. Supponendo di disporre di un sistema di sincronizzazione riconosciuto da tutti i nodi della rete, e di conoscere i periodi temporali in cui un nodo è reperibile (sempre in relazione al sistema di sincronizzazione usato), allora è possibile prevedere e programmare i momenti più opportuni in cui effettuare una trasmissione. Un esempio calzante è ancora una volta quello delle trasmissioni spaziali, come illustrato in Fig Figura 2.5: Esempio di Scheduled Communication. [3] 24

25 2.2. FUNZIONAMENTO Un nuovo livello: il Bundle Layer L architettura DTN implementa il sistema dello Store-And-Forward Message Switching attraverso l adozione di un nuovo protocol layer, posizionato al di sopra dei sotto layer specifici delle varie reti eterogenee. Questo nuovo livello viene chiamato bundle layer ed ha il compito di raccordare tra loro le varie reti al fine di permettere la trasmissione di messaggi (bundle) attraverso diverse regioni della rete. Esiste quindi un unico bundle layer protocol per tutte le regioni della rete, mentre per quanto riguarda i layer inferiori ogni regione è libera di adottare i propri protocolli. In Fig. 2.6 possiamo vedere le differenze tra l architettura della rete Internet e quella DTN. Figura 2.6: Confronto tra l architettura a layer Internet e DTN [3] Abbiamo appena detto che l unita di trasmissione delle DTN è il bundle. Ogni bundle si compone fondamentalmente da tre parti: 1. source-appliction s user data: ovvero i dati veri e propri. 2. control information: insieme di indicazioni per permettere il corretto trattamento dei dati. 3. bundle header: header di controllo inserito dal bundle layer. Così come i dati, anche i bundles possono essere di dimensione arbitraria (quindi variabile), e all occorrenza possono essere frammentati e spediti 25

26 CAPITOLO 2. DTN: DELAY TOLERANT NETWORK indipendentemente, per poi essere riasseblati dal bundle layer del destinatario. Fondamentalmente dunque il bundle non è altro che un ulteriore passo di incapsulamento dell informazione, come possiamo vedere dalla Fig. 2.7 che mostra un chiaro esempio di come il bundle layer lavora in un contesto operante al di sopra di una regione di rete basata su TCP/IP. Figura 2.7: Evoluzione di un bundle. [3] Il funzionamento del bundle protocol così come le caratteristiche strutturali del bundle sono descritte nel documento di riferimento RFC 5050 [1]. 26

27 2.2. FUNZIONAMENTO Bundle Protocol Protocolli come il TCP, fortemente conversazionali, comportano un elevato numero di round-trips che possono risultare ingestibili nel caso in cui ci siano delay particolarmente lunghi. Pertanto i bundle layers comunicano tra loro attraverso l uso di un protocollo non conversazionale che minimizza o azzera il numero di round-trips, rendendo opzionali gli acknowledgement (Fig. 2.8). Ovviamente i livelli inferiori su cui appoggia il bundle layer possono comunque utilizzare protocolli conversazionali come il TCP, ma esiste la possibilità di usare anche protocolli meno loquaci. Figura 2.8: Protocollo non conversazionale. I dettagli relativi al formato dei bundle o più in generale all applicazione del bundle protocol verranno forniti nel capitolo relativo alla progettazione, in modo da rendere più efficaci le spiegazioni e motivare le scelte fatte. 27

28 CAPITOLO 2. DTN: DELAY TOLERANT NETWORK 28

29 Capitolo 3 La piattaforma Android Figura 3.1: Android in esecuzione su un HTC Evo 4G. Android è una piattaforma per dispositivi mobili che comprende al suo interno un sistema operativo, middleware e applicazioni di base [4]. Il sistema operativo di Android è open-source ed è sostanzialmente basato sul sistema operativo GNU/Linux. Fu inizialmente sviluppato da Android Inc., azienda acquisita nel 2005 da Google. Proprio i co-fondatori di Android Inc. (Andy Rubin, Rich Miner, Nick Sears e Chris White) iniziarono a lavorare per la stessa Google e svilupparono una piattaforma basata sul kernel Linux, presentata per la prima volta il 5 novembre 2007 all Open Handset Alliance e operante con la famosa versione 2.6 del kernel. Attualmente la piattaforma (disponibile nella versione 2.2) si trova nel 29

30 CAPITOLO 3. LA PIATTAFORMA ANDROID boom della sua diffusione e rappresenta la principale rivale del sistema targato Apple, soprattutto grazie alla partnership ufficiale instaurata tra Google e HTC (Fig. 3.1), noto fornitore di dispositivi smartphone, che ha contribuito enormemente alla diffusione di Android. La scelta di utilizzare Android come piattaforma su cui sviluppare il client MDTN non è scaturita solo dal questo aspetto, ma bensì dalle caratteristiche funzionali e prestazionali che tale sistema è in grado di offrire. Nelle prossime sezioni ci occuperemo di elencare e spiegare tali caratteristiche in modo da capire cosa rende Android tanto allettante. 3.1 Panoramica generale Effettueremo ora una panoramica generale su Android per evidenziare le principali caratteristiche di questa piattaforma. Gli elementi caratterizzanti sono i seguenti: Android SDK: possibilità di utilizzare il kit di sviluppo applicazioni che, attraverso strumenti ed API, permette la realizzazione di applicazioni per Android in linguaggio Java. Dalvik virtual machine: i programmi vengono eseguiti su questa particolare Java virtual machine, ottimizzata per dispositivi mobili. Supporto ai più comuni formati multimediali audio, video, e immagini (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF). Supporto per telefonia basata su GSM e CDMA (dipendente dall hardware). Supporto per tecnologie Bluetooth, EDGE, 3G, 4G, Wi-Fi e WiMAX (dipendente dall hardware). Supporto per fotocamera, GPS, bussola, ed accelerometro (dipendente dall hardware). Browser integrato basato sul motore del browser open source WebKit. Supporto SQLite per la memorizzazione di dati strutturati su database. Schermate grafiche ottimizzate, sostenute da una libreria grafica 2D personalizzata; grafica 3D basata sulla specificazione OpenGL ES 1. 1 OpenGL ES: 30

31 3.2. L ARCHITETTURA 3.2 L architettura Il diagramma in Fig. 3.2 mostra com è strutturata la piattaforma Android. Seguono le spiegazioni dettagliate degli scopi e delle funzionalità di ogni livello. Figura 3.2: Architettura della piattaforma Android. [4] Livello Application Android mette a disposizione un set di applicazioni di base, che comprende un client di posta, un programma SMS, calendario, mappe, browser, contatti e altro (tutte le applicazioni sono scritte in linguaggio Java). I file contenenti le applicazioni sono contrassegnati dall estensione.apk. Livello Application Framework Gli sviluppatori hanno pieno accesso alle stesse API usate dalle applicazioni di base. L architettura delle applicazioni è progettata per semplificare 31

32 CAPITOLO 3. LA PIATTAFORMA ANDROID il riutilizzo dei componenti; ogni applicazione può rendere pubbliche le sue risorse in modo che tutte le altre applicazioni possano farne uso (pur essendo soggette ai limiti di sicurezza imposti dal framework). Questo stesso meccanismo consente all utente di sostituire i componenti standard con versioni personalizzate. In generale, alla base di ogni applicazione si trova un set di servizi e risorse fondamentali tra cui: Un gruppo ricco ed estendibile di View che possono essere usate per costruire un applicazione; contiene liste, caselle di testo, pulsanti, e addirittura un browser web integrato. Dei Content Providers che permettono alle applicazioni di accedere a dati di altre applicazioni (come i Contatti), o di condividere i propri dati. Un Manager delle risorse, che offre l accesso a risorse come elementi grafici, files di layout, ecc. Un Manager delle notifiche, che permette a tutte le applicazioni di mostrare avvisi personalizzati nella status bar. Un Manager delle attività, che gestisce il ciclo di vita delle applicazioni. Livello Libraries Android comprende un set di librerie C/C++ usate da varie componenti del sistema. Tali elementi sono presentati allo sviluppatore attraverso il framework per lo sviluppo delle applicazioni. Queste sono alcune delle librerie principali: System C library: un implementazione BSD-derived della libreria standard C (libc), disegnata per dispositivi basati su Linux. Media Libraries: librerie multimediali basate sull OpenCORE di PacketVideo; le librerie supportano la riproduzione e la registrazione di molti popolari formati audio e video, compresi file di immagini, inclusi MPEG4, H.264, MP3, AAC, AMR, JPG, e PNG. Surface Manager: gestisce l accesso al display subsystem e compone layer grafici 2D e 3D da applicazioni multiple. LibWebCore: un motore di browser moderno che fa funzionare sia il browser Android sia la visualizzazione web implementata. 32

33 3.3. CICLO DI VITA DI UN APPLICAZIONE SGL: librerie per l accesso al motore grafico 2D sottostante. 3D libraries: un implementazione basata su API OpenGL ES 1.0; le librerie usano sia accelerazione hardware 3D (quando disponibile) sia quella software (un rasterizer 3D altamente ottimizzato). SQLite: un motore di database relazionale potente e leggero disponibile per tutte le applicazioni. Livello interno Runtime Android comprende un set di librerie centrali che forniscono la maggior parte delle funzionalità disponibili nelle librerie di base del linguaggio di programmazione Java. Tutte le applicazioni Android vengono eseguite su processi dedicati attraverso virtual machine Dalvik dedicate. Dalvik è stata scritta in modo che un dispositivo possa eseguire VMs multiple in modo efficiente. Essa esegue i files nel formato Dalvik Executable (caratterizzato dall estensione.dex), che è ottimizzato per funzionare con un minimo spazio di memoria. La VM è register-based e funziona con classi compilate da un compilatore Java, trasformate in un formato.dex automaticamente dalla VM stessa. La VM Dalvik si appoggia sul kernel Linux per funzioni di base come la gestione di threading e situazioni di livelli minimi di memoria. Livello Kernel Linux Android si appoggia alla versione 2.6 del kernel Linux per servizi del sistema centrale come sicurezza, gestione della memoria, esecuzione, network stack e driver. Il kernel funziona anche da abstraction layer tra l hardware e il resto del software. 3.3 Ciclo di vita di un applicazione Come già citato, ogni applicazione Android viene avviata all interno di una Dalvik VM dedicata, che viene avviata su un processo Linux dedicato. Tale processo continuerà ad essere in esecuzione fino a quando non sarà più necessario e il sistema dovrà recuperare la sua memoria per usarla per altre applicazioni. Una caratteristica inusuale ma fondamentale di Android è il fatto che la vita del processo di un applicazione non è direttamente controllata dall applicazione stessa. E invece determinata dal sistema 33

34 CAPITOLO 3. LA PIATTAFORMA ANDROID attraverso una combinazione delle parti dell applicazione che il sistema sa essere in esecuzione, attraverso l importanza che queste hanno per l utente e quanta della memoria complessiva è ancora disponibile nel sistema. Per determinare quali processi devono essere portati a termine quando il sistema è a corto di memoria, Android li colloca in una lista ordinata per ordine di importanza basata sui componenti in esecuzione e sui loro stati. I tipi di processi, in ordine di importanza, sono i seguenti: 1. Un processo di primo piano (foreground process) è un processo indispensabile per l attività che l utente sta correntemente svolgendo. Vari componenti di un applicazione possono portare il processo che li contiene ad essere considerato di primo piano, in modi diversi. Ci saranno sempre solo un paio di processi del genere nel sistema, e questi saranno portati a termine solo come ultima risorsa possibile per recuperare memoria se risulta così bassa da non riuscire ad alimentare neanche questi processi. Generalmente a questo punto il dispositivo ha raggiunto una condizione tale per cui questa azione è necessaria per mantenere l interfaccia utente reattiva. 2. Un processo visibile (visible process) è un processo che gestisce una activity che è visibile dall utente sullo schermo ma non in primo piano (il suo metodo onpause() è stato richiamato). Questo può accadere, per esempio, se l attività in primo piano è stata presentata attraverso un pannello che permette all attività precedente di essere vista dietro di esso. Un processo tale è considerato molto importante e non verrà portato forzatamente a termine a meno che non sia necessario per mantenere in esecuzione tutti i processi di primo piano. 3. Un processo di servizio (service process) è un processo che gestisce un servizio che è stato avviato con il metodo startservice(). Anche se questi processi non sono direttamente visibili dall utente, generalmente svolgono compiti di suo interesse (come la riproduzione di mp3 sullo sfondo o upload o download di dati di rete), quindi il sistema manterrà sempre questi processi in esecuzione almeno che non ci sia abbastanza memoria per mantenere tutti i processi di primo piano e visibili. 4. Un processo di sfondo (background process) è un processo che gestisce un attività che non è correntemente visibile all utente (è stato richiamato il suo metodo onstop()). Questi processi non hanno un impatto diretto sull interazione dell utente. Il sistema può portarli a termine in ogni momento per recuperare memoria per uno dei tre tipi di processo precedenti. In genere ci sono molti processi di questo tipo in esecuzione, vengono quindi tenuti 34

35 3.4. SVILUPPO in una lista LRU per assicurare che il processo che è stato visto dall utente più recentemente sia portato a termine per ultimo in caso di carenza di memoria. 5. Un processo vuoto (empty process) è un processo che non gestisce nessun componente attivo dell applicazione. L unica ragione per mantenere un tale processo a disposizione è considerarlo come una cache per migliorare il tempo di avviamento la prossima volta che un componente della sua applicazione deve essere eseguito. Il sistema porterà sovente a termine questi processi per bilanciare le sue risorse complessive. Una volta classificato il processo, il sistema individua quali sono i componenti attivi che operano in esso e valuta l importanza complessiva dell intera attività. Ogni singola classe è dotata di una documentazione che descrive dettagliatamente quel è l influenza di tale classe sul ciclo di vita complessivo dell applicazione ( 2 ). 3.4 Sviluppo Android spicca sicuramente per l attenzione e l accuratezza che viene data al settore dello sviluppo delle applicazione da parte degli utenti. Attraverso il suo potente e ricco ambiente di sviluppo (che include un emulatore, strumenti per debugging, profiling della memoria e delle prestazioni e un plug-in per l IDE Eclipse), possiamo sicuramente dire che questo nuovo sistema ha catturato il cuore di molti sviluppatori Android SDK Come appena detto, l SDK è fornito di svariati tool e librerie da poter utilizzare per realizzare le proprie applicazioni. Per quanto concerne l installazione e la configurazione dell ambiente di sviluppo, rimandiamo alle ottime istruzioni disponibili sul sito ufficiale [4]. Vale la pena però di spiegare quali sono i tool indispensabili tra quelli disponibili e quali sono le loro funzionalità principali. Android Emulator: L emulatore del sistema Android. Permette agli sviluppatori di testare le proprie applicazioni senza la necessità di doverle installare 2 Si rimanda alla documentazione ufficiale 35

36 CAPITOLO 3. LA PIATTAFORMA ANDROID fisicamente sul proprio dispositivo. In un certo senso permette anche a coloro che non dispongono fisicamente di un dispositivo Android di realizzare applicazioni e quindi di avvicinarsi con curiosità alla piattaforma. Ad ogni modo le prestazioni dell emulatore sono decisamente inferiori a quelle del device reale, pertanto per attività di sviluppo minimamente serie è comunque consigliabile utilizzare un dispositivo fisico, senza contare che l emulatore in sé consuma parecchie risorse sulla propria postazione di lavoro. Android Virtual Devices (AVDs): Tool per la creazione e gestione di dispositivi virtuali da utilizzare all interno dell emulatore. E possibile configurare degli smartphone virtuali su misura delle nostre esigenze per poi utilizzarli nell ambiente emulato. Android Debug Bridge (adb): Questo tool permette di installare automaticamente le proprie applicazioni sul device collegato alla postazione di lavoro (via USB) e di eseguirle in una modalità di debugging. Questo tool è fondamentale in quanto permette di testare rapidamente le applicazioni (direttamente sul telefono) e di disporre di tutte le informazioni di debug (sulla propria postazione di lavoro). zipalign: Un particolare tool che permette di ottimizzare le nostre applicazioni una volta che questo sono state esportate nel formato.apk. Come per la guida completa all installazione e alla configurazione, per i restanti tool rimandiamo alla lista completa disponibile all indirizzo ufficiale Integrazione con l ambiente di sviluppo Eclipse L aspetto letteralmente eccezionale dell SDK è proprio quello di fondersi completamente con uno dei migliori ambienti di sviluppo attualmente in circolazione: Eclipse. Ormai strumento di sviluppo affermato e riconosciuto, Eclipse è stato scelto anche da Android per la sua ottima capacità di estensione ed adattamento ai più svariati contesti lavorativi. L eccezionale sistema di plug-in permette infatti di adattare l IDE a quasi qualsiasi esigenza, tra cui ovviamente quella di realizzare applicazioni per Android. Attraverso il plug-in ADT (Android Development Tools Plugin) scaricabile dal sito ufficiale è possibile trasformare in pochi minuti la propria versione di Eclipse in un ambiente di sviluppo dedicato. Tale plug-in riesce sostanzialmente a fondere la totalità dei tool disponibili all interno 36

37 3.4. SVILUPPO dell interfaccia dell IDE, rendendo estremamente semplici le operazioni di avvio, debugging ed esportazione delle applicazioni. Potremo quindi gestire i nostri device virtuali, avviare le nostre applicazioni scegliendo quale dispositivo utilizzare (inclusi quelli fisici), accedere alla gestione dei processi e del file system del dispositivo (o dei dispositivi) collegati tramite USB, catturare screen-shot direttamente dalla schermata del device, ecc... Figura 3.3: ADT in esecuzione su Eclipse. L utilizzo sistematico di Eclipse per lo sviluppo di applicazioni Android porta senza alcun dubbio ad un abbattimento dei tempi di sviluppo, pertanto il suo uso è estremamente consigliato. 37

38 CAPITOLO 3. LA PIATTAFORMA ANDROID 38

39 Capitolo 4 Resoconto dell attività di individuazione e analisi di un Framework per DTN Il primo passo che è stato fatto prima di procedere con la progettazione di MDTN è stato quello di cercare di individuare dei potenziali framework per DTN da poter utilizzare ai fini di semplificare la progettazione stessa ed abbassare i tempi di sviluppo. In questo capitolo presenteremo quali sono state le fasi di questa attività e quali considerazioni hanno portato. 4.1 La ricerca L attività di individuazione di un eventuale Framework per DTN si è rivelata tutt altro che semplice. Essendo l applicazione di tale architettura di rete in ambito mobile una materia ancora giovane ed in fase di sviluppo, esistono ben poche applicazioni in grado di sfruttarne il principio di comunicazione, come poco è il materiale reperibile in rete. Inoltre bisogna ricordare che in origine tale architettura di rete è stata pensata per cercare delle soluzioni ai problemi di comunicazione nello spazio relativi alla realizzazione di reti interplanetarie, pertanto alcune assunzioni e supposizioni presenti nei documenti di riferimento RFC4838 [2] e RFC5050 [1] risultano non avere una controparte in questo contesto applicativo. Nonostante queste difficoltà di fondo è stato individuato un interessante progetto del Royal Institute of Technology di Stoccolma, denominato Bytewalla, il cui target primario è appunto la realizzazione di una delay tolerant network attraverso l uso di telefoni Android. 39

40 CAPITOLO 4. RESOCONTO DELL ATTIVITÀ DI INDIVIDUAZIONE E ANALISI DI UN FRAMEWORK PER DTN L attività di ricerca si è dunque conclusa individuando Bytewalla come possibile Framework da utilizzare per lo sviluppo del progetto. 4.2 Bytewalla Il progetto Bytewalla è stato realizzato nel 2009 dal Telecommunication Systems Laboratory (TSLab) del Royal Institute of Technology di Stoccolma ed è stato presentato al pubblico nel gennaio 2010 [5]. Tale progetto, sviluppato da un team di sei persone, è nato con lo scopo di realizzare un infrastruttura di rete in grado collegare le zone rurali africane con le aree urbane sfruttando i principi del delay tolerant networking e utilizzando i telefoni Android come data-mule Funzionamento Per comprendere il funzionamento di base di Bytewalla possiamo aiutarci con il diagramma architetturale in Fig. 4.1: Figura 4.1: Diagramma architetturale di Bytewalla [5] Dal diagramma risulta subito evidente la presenza di due reti distinte: la Village Network e la City Network. All interno della Village Network (ovvero nella zone rurale priva di connessione Internet) è presente un proxy in grado di raccogliere e gestire le richieste degli utenti attraverso l erogazione di un servizio Wi-Fi (per semplicità assumiamo che i servizi richiesti 40

41 4.2. BYTEWALLA degli utenti si riferiscano al semplice invio di messaggi ). Tale proxy attende l arrivo di un data-mule, concretamente rappresentato da un telefono Android, per consegnare i dati e le richieste precedentemente raccolte (sotto forma di bundle). Il data-mule, dopo aver raccolto i bundle provenienti dalla Village Network si rimette in viaggio e, potenzialmente, incontra altri data-mule con i quali può scambiare e propagare i bundle. In questo modo i bundle vengono trasportati fisicamente fino alla città (ovvero all interno della City Network). All interno della City Network è presente un gateway in grado di raccoglie ed interpretare i bundle provenienti dai vari data-mule. Il gateway dispone della connettività Internet, pertanto è in grado di soddisfare le richieste effettuate dagli utenti del villaggio che sono pervenute sotto forma di bundle, inviando fisicamente i messaggi attraverso la rete. Dualmente, i bundle possono essere inviati dalla City Network verso la Village Network con la stesso procedimento, garantendo la bidirezionalità della comunicazione. Concretizziamo la spiegazione con un semplice esempio: un utente del villaggio desidera inviare una ma non dispone di alcun accesso ad Internet. Collegandosi al proxy del villaggio esso inoltra una richiesta di invio contenente tutte le informazioni necessarie (destinatario, oggetto del messaggio, corpo del messaggio...), la quale viene trasformata in un bundle e memorizzata dal proxy in attesa dell arrivo di un data-mule. Nel frattempo un turista (oppure un postino in moto) della città arriva in visita al villaggio, portandosi appresso il proprio telefono Android. Il proxy rileva la presenza di questo potenziale data-mule e reindirizza su di esso i bundle precedentemente memorizzati. A questo punto il data-mule è carico di bundle che attendono di essere trasportati in città. Il turista (o il postino) termina la propria visita al villaggio e ritorna in città. A questo punto, il data-mule rientra nel raggio di azione del gateway cittadino, il quale raccoglie ed interpreta i bundle provenienti dal villaggio ed invia fisicamente l attraverso Internet Architettura a layer L architettura a layer di Bytewalla è composta fondamentalmente da tre livelli: BP Application Layer, Bundle Protocol e Convergence Layer (che sono a tutti gli effetti i layers previsti dalla classica architettura DTN). Non sono state fatte particolari modifiche a livello di Link layer, pertanto 41

42 CAPITOLO 4. RESOCONTO DELL ATTIVITÀ DI INDIVIDUAZIONE E ANALISI DI UN FRAMEWORK PER DTN è stato utilizzato direttamente il TCP/IP. Figura 4.2: Diagramma dell architettura a layer di Bytewalla [5] Come rappresentato in Fig. 4.2 l aspetto peculiare di tale architettura risiede nella tipologia di layer che vengono implementati sulla piattaforma Android. Infatti per i dispositivi Android non è richiesto alcun livello di BP Application, in quanto il loro unico compito è quello di operare come bundle-carriers. Conseguentemente sono i gateway/proxy server ad implementare il BP Application Layer fornendo le applicazioni specifiche (es. servizio DTN mail) Confronto con MDTN Nonostante la generica somiglianza, Bytewalla presenta delle differenze sostanziali rispetto a ciò che questo progetto mira a realizzare. Tali differenze spaziano dal puro contesto applicativo all architettura stessa del sistema. A partire dal confronto tra il diagramma architetturale di Bytewalla e quello di MDTN (Fig. 5.1) si possono individuare subito delle differenze di fondo per quanto riguarda i ruoli delle varie entità coinvolte nel processo di comunicazione. E stato effettuato un confronto fra le caratteristiche delle due architetture in modo da rendere più chiare le differenze tra quest ultime, come è possibile vedere nella tabella

43 4.2. BYTEWALLA Figura 4.3: Diagramma architetturale di MDTN Bytewalla I dispositivi Android ricoprono il ruolo di carriers e non dispongono di altre funzionalità. Gateway e proxy sono entità distinte con compiti distinti, inoltre sono statici. Il gateway dispone di un connettività Internet stabile. MDTN I dispositivi Android sono i veri e propri utilizzatori del servizio e dispongono delle varie funzionalità. Il ruoli di proxy e di gateway vengono racchiusi in un unica entità che funge anche da carrier. Il carrier è per natura propria in continuo movimento. Il carrier (che contiene anche il gateway) non dispone di una connettività Internet stabile. Tabella 4.1: Confronto tra Bytewalla e MDTN 43

44 CAPITOLO 4. RESOCONTO DELL ATTIVITÀ DI INDIVIDUAZIONE E ANALISI DI UN FRAMEWORK PER DTN Tali caratteristiche contrastanti si rispecchiano naturalmente nelle due architetture a Layer che risultano essere quindi fortemente distinte. Prendendo visione del diagramma architetturale di Fig. 4.4 ci si rende conto che l implementazione del BP Application Layer su piattaforma Android (fondamentale per MDTN e non previsto in Bytewalla) rappresenta forse la problematica principale che potrebbe sorgere dall adozione di Bytewalla come base, assieme al fatto che quest ultimo è stato pensato e progettato per funzionare in una modalità che, di fatto, risulta essere completamente diversa (quasi specchiata) rispetto a quella di MDTN. Figura 4.4: Diagramma dell architettura a layer di MDTN Analisi preliminare del codice e della documentazione Il codice sorgente di Bytewalla è organizzato in 20 package, contenenti all incirca 260 classi Java per un totale di quasi linee di codice. Tale mole di informazioni è supportata da una documentazione Javadoc che purtroppo risulta essere altamente superficiale e strettamente indirizzata agli sviluppatori. Di fatto, Bytewalla non è un Framework ma bensì una semplice applicazione. Pertanto le informazioni che fanno da contorno al codice sorgente risultano essere largamente insufficienti alla comprensione e all utilizzo diretto del codice per persone diverse dagli sviluppatori stessi. 44

45 4.3. CONCLUSIONE Non è presente alcun tipo di guida all uso delle classi che vengono messe a disposizione e non vengono resi disponibili i documenti progettuali dettagliati del progetto. Tanto meno non esistono guide o tutorial (anche non ufficiali) che tentino di spiegare come implementare i propri programmi. Le uniche risorse disponibili sono limitate ai documenti di facciata reperibili all indirizzo ufficiale del progetto (Business documents, presentazioni, ecc), che non forniscono alcuna informazione utile allo sviluppo. 4.3 Conclusione Le differenze sostanziali tra i due progetti, sommate all insufficiente documentazione, scoraggiano dall idea di adottare Bytewalla come base di partenza. Grazie all esperienza pregressa ottenuta dallo sviluppo del progetto di Ingegneria del Software risulta evidente che non è possibile riutilizzare del codice di cui non si conosce il comportamento in quanto l overhead temporale per lo studio e la comprensione di linee di codice porterebbe subito all esaurimento del monte ore disponibile. Si è ritenuto dunque preferibile realizzare una propria versione semplificata di un protocollo DTN-like (sempre cercando di mantenere le linee guida dei documenti RFC4838 e RFC5050) in grado di permettere l effettiva implementazione dei servizi previsti e che sia il più possibile estendibile. 45

46 CAPITOLO 4. RESOCONTO DELL ATTIVITÀ DI INDIVIDUAZIONE E ANALISI DI UN FRAMEWORK PER DTN 46

47 Capitolo 5 Analisi dei requisiti In questo capitolo ci occuperemo di analizzare le caratteristiche e le funzionalità del sistema MDTN ai fini di individuare i requisiti necessari alla sua realizzazione. Per fare ciò ci serviremo di diagrammi architetturali ad alto livello del sistema e di diagrammi use-case in grado di evidenziare ed estrapolare i requisiti fondamentali. 5.1 Funzionalità del prodotto Le funzionalità messe a disposizione dell utente saranno fondamentalmente degli specifici servizi Internet, implementati secondo il principio delle DTN. L utente, una volta salito a bordo del carrier, potrà inviare e richiedere delle generiche risorse reperibili su Internet utilizzando il client MDTN attraverso il proprio dispositivo Android. Le risorse ottenute tramite il servizio saranno fruibili attraverso specifici viewer o tramite applicazioni standard già presenti sulla piattaforma. Opzionalmente, gli utenti potranno interagire tra loro ai fini di formare dei gruppi atti alla condivisione di banda e risorse. Il server MDTN dovrà ovviamente occuparsi della gestione delle richieste dei client e dovrà quindi essere in grado di garantire il servizio di invio e download risorse. Per fare ciò il server dovrà sfruttare due diversi tipi di connettività: la prima, quella Internet, verrà utilizzata (quando presente) per soddisfare concretamente le richieste pendenti dei client; la seconda, quella relativa al servizio wireless erogato dal server, verrà utilizzata per comunicare e scambiare dati con i client stessi. 47

48 CAPITOLO 5. ANALISI DEI REQUISITI 5.2 Contesto d uso del prodotto Il contesto d uso del prodotto si colloca all interno di uno scenario urbano, caratterizzato dalla presenza di numerosi fonti erogatorie del servizio (carriers) e da un traffico variabile di utenza che si connette e disconnette in continuazione dal servizio. Tale dinamicità suggerisce di prestare una particolare attenzione ai sistemi di gestione della ricezione e consegna dell informazione, in quanto la possibilità di errore e/o interruzione della trasmissione è fondamentalmente elevato. 5.3 Caratteristiche degli utenti Non è richiesta alcuna particolare competenza da parte degli utenti utilizzatori del servizio. Semplicemente è richiesta la dimestichezza nell utilizzo del proprio dispositivo Android e dei principali servizi Internet. Per tal motivo l interfaccia del client dovrà essere semplice, intuitiva e corredata di help contestuali nel caso si necessiti di specificare qualche impostazione di carattere minimamente tecnico. Sarà invece richiesta una minima competenza in ambito tecnico per quanto riguarda l installazione e la configurazione del server, che sarà comunque accompagnato da un manuale d uso e configurazione chiaro e dettagliato. 5.4 Assunzioni e dipendenze Il servizio MDTN, per sua natura, presenta evidenti problematiche per quanto riguarda l aspetto della sicurezza (basti pensare, ad esempio, al potenziale pericolo di attacchi di tipo Man in the middle durante il processo di invio di una mail). La realizzazione di un servizio totalmente sicuro e protetto da attacchi esterni risulta però essere un pretesa eccessiva al fronte del monte ore disponibile ed esula dallo scopo stesso dello stage. Pertanto, si assume che tutte le comunicazioni avvengano su canali sicuri, privi di interferenze e protetti da accessi indesiderati. 5.5 Modalità La modalità operativa del servizio è fondamentalmente quella di una classica applicazione client-server. Il server installato a bordo del carrier ero- 48

49 5.6. DIAGRAMMA ARCHITETTURALE gherà un servizio tramite Wi-Fi al quale i vari client (ovvero i vari dispositivi Android) potranno collegarsi per effettuare le proprie richieste. Si denotano quindi due modalità di funzionamento per il client: modalità online: il client è collegato al servizio e può inviare richieste e ricevere risorse. modalità offline: il client non è collegato al servizio, non può quindi inviare richieste o ricevere risorse. Può però accedere a risorse precedentemente ottenute, oppure consultare il registro delle attività. Similmente, anche per il server si hanno due modalità operative: modalità gathering: il server non dispone di connettività Internet, pertanto si limita a raccogliere le richieste dei client o eventualmente a fornirgli delle risorse precedentemente ottenute. modalità digesting: il server dispone della connettività Internet e può quindi processare le varie richieste pervenute durante la fase di gathering. In questa modalità dunque, verranno fisicamente inviate le e scaricate le risorse necessarie per renderle successivamente disponibili agli utenti. La modalità di digesting non preclude quella di gathering, pertanto gli utenti possono continuare ad effettuare richieste mentre il server ne processa altre. 5.6 Diagramma architetturale Possiamo dare una rappresentazione ad alto livello di quella che è l architettura di base del sistema, in modo da fissare quanto detto fin ora, attraverso il diagramma architetturale di Fig Tale diagramma evidenzia il funzionamento del sistema nel caso base, ovvero nel caso in cui l utente effettua le richieste e riceve le risorse a bordo dello stesso carrier. Possiamo aiutarci con questo esempio pratico: un utente sale a bordo dell autobus e si ricorda di dover spedire una mail. Si collega al servizio Wi-Fi del carrier tramite il suo dispositivo mobile e richiede il servizio di invio mail. Compila il form con tutti i dati necessari e richiede l invio del messaggio. Il sistema prende in carico la richiesta e appena il carrier 49

50 CAPITOLO 5. ANALISI DEI REQUISITI Figura 5.1: Diagramma architetturale del sistema. raggiunge una zona in cui dispone della connettività Internet invia l . Quando l utente risale a bordo dell autobus, il sistema notifica l avvenuta consegna dell .. Possiamo però estendere questa situazione di base, introducendo un ulteriore entità per rappresentare il funzionamento in uno scenario esteso più realistico (Fig. 5.2). Figura 5.2: Diagramma architetturale del sistema nello scenario esteso. Nello scenario esteso (che verrà implementato opzionalmente) l utente sarà in grado di specificare un carrier di destinazione diverso da quello di partenza, in modo tale da poter ottenere determinate risorse su uno specifico carrier e non per forza sul carrier di partenza a cui viene inviata la richiesta. Possiamo sempre concretizzare questa spiegazione con un esempio 50

51 5.7. USE-CASE pratico: un pendolare compie la stessa tratta tutti i giorni spostandosi in autobus. Alla mattina sale a bordo dell autobus n 4 e si collega al servizio del carrier. Sa che tornerà a casa la sera dopo le cinque con l autobus n 6 e avrebbe piacere di potersi guardare un certo sito (o un qualsiasi altro file disponibile su Internet) durante il viaggio di ritorno. Attraverso il suo dispositivo mobile si collega al servizio Wi-Fi del carrier ed effettuala richiesta, la quale sarà deviata al carrier di destinazione (l autobus n 6), che dovrà occuparsi di soddisfarla. Alla sera l utente sale a bordo dell autobus n 6 e può accedere alla risorsa richiesta al mattino. 5.7 Use-case Attraverso l analisi dei casi d uso sono stati estrapolati i requisiti necessari alla realizzazione del progetto Use-case 1: Client DTN In questo caso d uso verranno evidenziate le interazioni tra l utente e il servizio attraverso del client DTN (Fig. 5.3). Figura 5.3: Use-case 1 - Client DTN 51

52 CAPITOLO 5. ANALISI DEI REQUISITI Pre-condizioni: Il programma client è pronto ad interagire con l utente. Descrizione sintetica: Il client fornisce un interfaccia all utente per poter utilizzare il servizio MDTN. Tale interfaccia sarà realizzata per la piattaforma Android e dovrà permettere l utilizzo di tutte le funzionalità precedentemente elencate in modo semplice ed intuitivo. Funzionamento di base: 1. L utente si collega al servizio MDTN usando il programma client tramite il proprio dispositivo Android. 2. Una volta collegato l utente può richiedere l invio di una mail o il download di una risorsa. 3. L utente può monitorare lo stato delle proprie richieste, oppure effettuarne delle nuove. 4. L utente può scaricare sul proprio dispositivo eventuali risorse ottenute dal server. Alternative: Non è disponibile alcun server DTN, pertanto l utente non può accedere al servizio e sfruttarne le funzionalità. Post-condizioni: Il client ha eseguito le operazioni richieste dall utente Use Case 2: Server DTN Questo caso d uso ha lo scopo di evidenziare l interazione tra client e server DTN (Fig. 5.4). Pre-condizioni: Il server è in attesa di richieste da parte dei client. Descrizione sintetica: Il server si occupa della gestione delle richieste provenienti dai client. In mancanza di connettività Internet, il server si limita a prendere in carico le richieste dei vari client e a fornire a quest ultimi le risorse di cui già dispone. Quando invece dispone delle connettività soddisfa il maggior numero possibile di richieste pendenti (inviando e scaricando file da Internet). 52

53 5.7. USE-CASE Figura 5.4: Use-case 2 - Server DTN Funzionamento di base: 1. Il client si collega al server attraverso un collegamento Wi-Fi. 2. Il client effettua delle richieste che vengono prese in carico dal server. 3. Il server accoglie le varie richieste, nel frattempo rimane in attesa della connessione Internet. 4. Il server, una volta ottenuta la connettività, soddisfa le richieste pendenti. 5. Il server mette a disposizioni eventuali risorse ottenute, oppure invia le notifiche di avvenuta consegna dei messaggi. 6. Il client accede alle risorse richieste e/o riceve delle notifiche relative ai messaggi che ha inviato in precedenza. Alternative: Il server non dispone mai di connettività Internet, pertanto non può soddisfare le richieste dei client. Post-condizioni: Il server ha soddisfatto le richieste dei client. 53

54 CAPITOLO 5. ANALISI DEI REQUISITI 5.8 Lista dei requisti Segue la lista dei requisiti che sono stati estrapolati grazie all analisi. Tali requisiti si suddividono in: obbligatori: requisiti esplicitamente richiesti dal capitolato che verranno obbligatoriamente realizzati. desiderabili: requisiti ritenuti importanti, anche se non necessariamente esplicitati nel capitolato, che verranno obbligatoriamente realizzati. opzionali: requisiti aggiuntivi di cui non si garantisce la realizzazione (a causa di rischio eccessivo, mancanza di risorse...) Requisiti obbligatori Realizzazione del servizio MDTN. Realizzazione del programma client per piattaforma Android e del programma server in linguaggio Java in grado di realizzare il servizio descritto precedentemente. Il client dovrà permettere all utente di collegarsi tramite il proprio telefono al servizio MDTN sfruttando la connessione Wi-Fi. Il client dovrà fornire un interfaccia semplice ed intuitiva sfruttando le potenzialità della piattaforma Android. L utente potrà inviare messaggi ( ) tramite il servizio MDTN. L utente potrà monitorare lo stato del servizio attraverso il client. Il server dovrà permettere ai client di connettersi tramite Wi-Fi. Il server dovrà implementare i propri servizi seguendo il principio delle DTN. Il server dovrà garantire il servizio di invio messaggi. 54

55 5.8. LISTA DEI REQUISTI Requisiti desiderabili L utente potrà richiedere una certa risorsa reperibile su internet tramite il servizio MDTN. Il server dovrà garantire il servizio di richiesta risorse. Il server dovrà garantire la persistenza delle risorse in modo appropriato. L utente potrà scaricare sul proprio telefono una risorsa precedentemente richiesta tramite il servizio MDTN. L utente disporrà di un limite di banda giornaliero da utilizzare per la richiesta di nuove risorse. Tale limite non potrà essere superato. Il server MDTN dovrà inviare una ricevuta di avvenuta consegna del messaggio all utente che lo ha spedito Requisiti opzionali Consentire a due o più utenti di accordarsi per formare un gruppo. Un gruppo deve disporre di una banda maggiore (rispetto al singolo utente) con la quale può richiedere delle risorse più corpose. Ogni utente del gruppo deve poter accedere alle risorse del gruppo stesso. Ogni utente del gruppo deve poter proporre la richiesta di una nuova risorsa. Un utente potrà richiedere che una specifica risorsa venga ottenuta e resa disponibile su un server DTN diverso da quello a cui è collegato al momento della richiesta (Scenario esteso). Il server DTN dovrà gestire una bacheca virtuale pubblica contenente le risorse che sono state rese disponibili a tutti gli utenti. Un utente che utilizza il servizio di richiesta risorse potrà richiedere esplicitamente di rendere pubbliche le risorse cercate e quindi di metterle a disposizione nella bacheca virtuale pubblica. 55

56 CAPITOLO 5. ANALISI DEI REQUISITI 56

57 Capitolo 6 Progettazione L attività di progettazione di client e server MDTN è ovviamente iniziata dalla progettazione dall elemento comune che collega queste due entità, ovvero il sistema di comunicazione. Tale fase ha impiegato molte risorse nello studio e nella comprensione delle linee guida espresse dai documenti di riferimento RFC4838 e RFC5050. Si è ritenuto fondamentale allinearsi a quanto indicato in tali documenti ai fini di implementare nel modo più corretto ed estendibile possibile il principio delle DTN. Allo stesso tempo, ponendosi l overlay DTN ad un livello relativamente alto (più precisamente tra Application Layer e Transport Layer), è stato possibile adottare alcune scelte e semplificazioni dovute al fatto che l implementazione sarebbe stata effettuata attraverso un linguaggio di programmazione Object Oriented (ovvero in Java). 6.1 Premesse architetturali Ai fini di allinearsi alle linee guida fornite dai documenti di riferimento sono state individuate una serie di premesse architetturali fondamentali per implementare nel modo corretto una DTN Componenti richieste In una DTN, ogni nodo in grado di inviare e ricevere bundle viene chiamato bundle node. Ognuno di questi nodi è in grado di eseguire tali operazioni grazie alla presenza di tre fondamentali componenti: BPA (Bundle Protocol Agent): Questo componente rappresenta il fornitore dei servizi offerti dal bundle layer. Costituisce sostanzialmente un interfaccia 57

58 CAPITOLO 6. PROGETTAZIONE per le applicazioni, tramite la quale sono in grado di comunicare all interno della DTN. Questo componente può essere implementato in moltissimi modi: come una libreria condivisa, come un demone di rete o direttamente a livello hardware. CLA (Convergence Layer Adapter): Questo componente ha il compito di inviare fisicamente i bundle attraverso le sotto-reti fisiche su cui appoggia il bundle layer. Pertanto deve utilizzare qualche tipo di protocollo nativo per poter inviare dati attraverso tali sotto-reti (ad esempio, TCP). Ogni bundle node può disporre di diversi CLA, a seconda del tipo di rete sottostante. AA (Application Agent): Componente che utilizza effettivamente i servizi offerti dal BPA ai fini di poter inviare o ricevere dati, ad esempio per permettere il corretto funzionamento di un applicazione. La nostra implementazione rispecchierà questa struttura di base, per ulteriori dettagli rimandiamo al paragrafo Formato dei Bundle Ogni bundle è costituito da un insieme di blocchi. Il numero di questi blocchi può variare a seconda della complessità del bundle e a delle tipologie di servizi adottati, ma sicuramente ci saranno sempre almeno due blocchi fondamentali: 1. Primary Block: blocco che contiene le informazioni di base relative al bundle, oltre alle indicazioni necessarie per portarlo a destinazione. 2. Payload Block: contiene i dati relativi all informazione veicolata dal bundle. Il formato di questi blocchi è descritto nel dettaglio alla pagina 18 di RFC Si è comunque deciso di effettuare qualche ritocco ai fini di semplificare nel complesso la gestione stessa del bundle. Tali ritocchi non pregiudicano assolutamente la logica intrinseca del formato proposto, semplicemente accorpano alcuni campi o aggiungono informazione. La versione utilizzata del formato per il Primary Block è rappresentata in Fig. 6.1 (le dimensioni delle varie celle sono puramente legate alla convenienza grafica in quanto tutti i campi sono a lunghezza variabile). I campi previsti sono i seguenti: 58

59 6.1. PREMESSE ARCHITETTURALI Version: la versione del protocollo usata (0x06 secondo RFC 5050). Processing control flags: insieme di flag che stabiliscono una serie parametri per la gestione del bundle (vedi RFC 5050, pg 14). Block length: dimensioni del blocco. Destination: URI che identifica il destinatario del bundle. Source: URI che identifica la sorgente del bundle. Report-to: URI che specifica il destinatario delle notifiche, se diverso dalla sorgente. Custodian: URI che identifica il nodo che custodisce questo bundle. Creation Timestamp time: timestamp del momento in cui è stato creato il bundle. Sequence number: numero di sequenza del bundle generato. Lifetime: tempo di vita del bundle. Fragment offset: se il bundle è un frammento, identifica la posizione dei dati di questo bundle in quello originale. Total ADU lenght: se il bundle è un frammento, rappresenta la dimensione totale dei dati originali. La versione utilizzata del formato per il Payload Block è rappresentata in Fig. 6.2 e comprende i seguenti campi: Block Type: tipologia del blocco generico. Fissato ad 1 per i blocchi di payload. Block Processing control flags: insieme di flag che stabiliscono una serie parametri per la gestione del blocco (vedi RFC 5050, pg 15). Bundle payload: i dati veri e propri, ovvero l informazione veicolata dal bundle. Block lenght: lunghezza del blocco. Type info: informazione aggiuntiva sul payload. 59

60 CAPITOLO 6. PROGETTAZIONE Figura 6.1: Primary Block Figura 6.2: Payload Block 6.2 Definizione dei componenti Definiremo ora quali sono le singolo componenti che andranno a formare l applicazione client e l applicazione server MDTN Metodo e formalismo di specifica Vengono di seguito descritti i diagrammi delle classi che costituiscono il sistema MDTN attraverso un approccio di tipo top-down: partendo da una visione complessiva e ad alto livello, si scenderà fino al dettaglio delle singole classi. Il formalismo adottato per le realizzazione di tali diagrammi è quello fornito dal linguaggio UML 1. 1 Specifica UML: 60

61 6.2. DEFINIZIONE DEI COMPONENTI Architettura generale del sistema e identificazione dei componenti architetturali di alto livello MDTN si struttura come un classico sistema client-server. Pertanto avremo dei componenti utilizzati esclusivamente dal client, altri usati esclusivamente dal server e una serie di elementi comuni. La strutturazione globale del sistema è rappresentata dal diagramma dei package in Fig Figura 6.3: Diagramma dei package di MDTN Descriviamo ora quali sono i ruoli principali dei vari package, per poi passare ad un analisi dettagliata di ognuno di essi. source.mdtn.bundle: Implementa il Bundle, così come definito in precedenza. 61

62 CAPITOLO 6. PROGETTAZIONE source.mdtn.comm: Fornisce i componenti fondamentali da utilizzare per la comunicazioni DTN. source.mdtn.android: MDTN. Costituisce l applicazione Android, ovvero il client source.mdtn.server: Costituisce il server MDTN. source.mdtn.util: Contiene una serie di componenti di generica utilità per tutti gli altri package Package source.mdtn.bundle Figura 6.4: Package source.mdtn.bundle Tipo, obbiettivo e funzione del componente: In questo package è presente l implementazione del Bundle precedentemente definito. Il bundle rappresenta l unità base della comunicazione attraverso reti DTN, pertanto ha una notevole importanza sia sotto l aspetto dell aderimento alle linee guida degli RFC sia per quanto riguarda la possibile compatibilità con altri sistemi. Relazioni d uso di altre componenti: 62

63 6.2. DEFINIZIONE DEI COMPONENTI Nessuna. Interfacce con e relazioni d uso da altre componenti: Il package viene sfruttato dai package source.mdtn.comm, source.mdtn.server, source.mdtn.android. Attività svolte e dati trattati: Le classi presenti in questo package si occupano della gestione del formato dell informazione, nonché dell interpretazione della stessa. Classe Block Tipo, obbiettivo e funzione del componente: Classe generica che rappresenta un generico blocco di dati da estendere a seconda delle esigenze. Relazioni d uso di altre componenti: Nessuna. Interfacce con e relazioni d uso da altre componenti: Questa classe viene estesa dalle classi PrimaryBlock e PayloadBlock. Attività svolte e dati trattati: La classe non svolge particolari attività se non quella di fornire una base strutturale per i blocchi di dati. Classe PrimaryBlock Tipo, obbiettivo e funzione del componente: Classe che rappresenta il blocco primario di un Bundle. Tale classe ha il compito di rappresentare l insieme delle informazioni considerate come header primario di un Bundle. Relazioni d uso di altre componenti: Estende la classe Block. Interfacce con e relazioni d uso da altre componenti: Utilizzata dalla classe Bundle. 63

64 CAPITOLO 6. PROGETTAZIONE Attività svolte e dati trattati: Detiene e fornisce informazioni sui dati utili alla gestione e al controllo del bundle. Classe PayloadBlock Tipo, obbiettivo e funzione del componente: Classe che rappresenta il blocco delle informazioni relative ai contenuti del bundle. Contiene la vera e propria informazione da trasmettere. Relazioni d uso di altre componenti: Estende la classe Block. Interfacce con e relazioni d uso da altre componenti: Utilizzata dalla classe Bundle. Attività svolte e dati trattati: In generale, funge da contenitore per dei dati veri e propri che devono essere trasmessi. Fornisce i metodi per l accesso e la manipolazione dei dati. Classe Bundle Tipo, obbiettivo e funzione del componente: Classe che rappresenta il bundle che costituisce il granello delle comunicazioni DTN. La totalità degli scambi di informazioni avvengono grazie all uso di questo particolare contenitore caratterizzato da diversi elementi modulari. Relazioni d uso di altre componenti: Il bundle si compone di un PrimaryBlock e di un PayloadBlock. Interfacce con e relazioni d uso da altre componenti: Utilizzata da tutti i componenti che agiscono più o meno direttamente sulla trasmissione. Attività svolte e dati trattati: Funge da veicolo per l informazione. Contiene sia dati relativi all informa- 64

65 6.2. DEFINIZIONE DEI COMPONENTI zione da trasmettere sia dei dati di controllo utili ad interpretare e gestire il bundle stesso. Fornisce anche i metodi per il recupero e il salvataggio persistente del bundle stesso Package source.mdtn.comm Figura 6.5: Package source.mdtn.comm Tipo, obbiettivo e funzione del componente: Il package contiene il cuore dei componenti che permettono la comunicazione attraverso la rete DTN. Relazioni d uso di altre componenti: Utilizza componenti del package source.mdtn.util e source.mdtn.bundle. Interfacce con e relazioni d uso da altre componenti: 65

66 CAPITOLO 6. PROGETTAZIONE Il package viene sfruttato dai package source.mdtn.server e source.mdtn.android. Attività svolte e dati trattati: Le classi qui contenute hanno il compito di rendere possibili le comunicazioni attraverso la rete DTN e di fornire i metodi necessari alla realizzazione dei servizi per gli utenti. Classe BundleProtocol Tipo, obbiettivo e funzione del componente: Classe che rappresenta l implementazione del bundle protocol. Relazioni d uso di altre componenti: Opera sui Bundle. Interfacce con e relazioni d uso da altre componenti: Usata genericamente da client e server per interpretare le comunicazioni di carattere generale nella rete DTN. Attività svolte e dati trattati: Interpreta i bundle attraverso una funzione di processing ed è in grado di generare, se necessario, un bundle di risposta. Tale classe fornisce un livello di isolamento aggiuntivo in quanto è indipendente dalla piattaforma e/o dall oggetto che la sta usando. Classe Report Tipo, obbiettivo e funzione del componente: Classe che rappresenta un Report informativo. Relazioni d uso di altre componenti: Nessuna. Interfacce con e relazioni d uso da altre componenti: Usata delle classi di comunicazione di questo package. Attività svolte e dati trattati: 66

67 6.2. DEFINIZIONE DEI COMPONENTI Fornisce una rappresentazione strutturata ai messaggi di report che vengono inviati sulla rete. Classe BundleNode Tipo, obbiettivo e funzione del componente: Componente fondamentale della struttura della rete DTN. Costituisce il core delle comunicazione, attraverso il quale è possibile interagire con la rete. Questo componente può essere inserito all interno di qualsiasi programma Java desideri comunicare sulla rete DTN, in quanto tutto il funzionamento è inglobato al suo interno. Relazioni d uso di altre componenti: Utilizza le classi del package source.mdtn.util e detiene un BPAgent. Interfacce con e relazioni d uso da altre componenti: Usata dalle applicazioni che sfruttano la rete DTN. Attività svolte e dati trattati: Fornisce i metodi e le funzionalità che permettono di comunicare ed ottenere servizi attraverso la rete DTN. Classe BPAgent Tipo, obbiettivo e funzione del componente: Classe che rappresenta il Bundle Protocol Agent definito in RFC Relazioni d uso di altre componenti: Utilizza un TcpAdapter per comunicare attraverso i livelli inferiori. Interfacce con e relazioni d uso da altre componenti: Usata dal BundleNode. Attività svolte e dati trattati: Fornisce i metodi e le funzionalità che permettono al BundleNode di funzionare al di sopra di altre reti. 67

68 CAPITOLO 6. PROGETTAZIONE Classe TcpAdapter Tipo, obbiettivo e funzione del componente: Classe che rappresenta uno specifico tipo di Convergence Layer Adapter (descritti in RFC 5050). Nel dettaglio, funge da adattatore tra l overlay della DTN e le reti basate su TCP/IP. Relazioni d uso di altre componenti: Utilizza i Bundle per la comunicazione. Interfacce con e relazioni d uso da altre componenti: Usata dal BPAgent. Attività svolte e dati trattati: Fornisce i metodi e le funzionalità che permettono di inviare e ricevere Bundle al di sopra di reti TCP/IP Package source.mdtn.android Figura 6.6: Package source.mdtn.android Tipo, obbiettivo e funzione del componente: 68

69 6.2. DEFINIZIONE DEI COMPONENTI Il package contiene le classi che vanno a formare il client DTN per la piattaforma Android. Relazioni d uso di altre componenti: Utilizza componenti del package source.mdtn.util e source.mdtn.comm. Inoltre utilizza le APIs dell Android SDK. Interfacce con e relazioni d uso da altre componenti: Nessuna. Attività svolte e dati trattati: Le classi qui contenute hanno il compito di implementare il client con tutte le sue funzionalità al fine di permettere l interazione dell utente con il sistema stesso. Classe MainActivity Tipo, obbiettivo e funzione del componente: Classe che rappresenta l attività principale del client, ovvero la prima componente che viene avviata all avvio del programma. Relazioni d uso di altre componenti: Utilizza un componente BundleNode per collegare Android alla rete MDTN. Utilizza le sotto-attività InfoActivity, StatusActivity, MailActivity, e FileActivity per fornire i diversi servizi all utente attraverso un interfaccia grafica. Interfacce con e relazioni d uso da altre componenti: Nessuna. Attività svolte e dati trattati: Fornisce l interfaccia di interazione principale con l utente, con un layout realizzato sotto forma di tab. Mette a disposizione tutti i servizi possibili attraverso l istanziazione di sotto-attività dedicate che garantiscono la fruibilità del sistema. Classe InfoActivity Tipo, obbiettivo e funzione del componente: 69

70 CAPITOLO 6. PROGETTAZIONE Classe informativa che fornisce alcuni dettagli sul programma. Relazioni d uso di altre componenti: Nessuna. Interfacce con e relazioni d uso da altre componenti: Sfruttata da MainActivity. Attività svolte e dati trattati: Visualizza una schermata informativa contenente informazioni utili riguardo l applicazione e il servizio MDTN. Classe StatusActivity Tipo, obbiettivo e funzione del componente: Classe di monitoraggio che permette di controllare e gestire la connessione al servizio MDTN. Relazioni d uso di altre componenti: Nessuna. Interfacce con e relazioni d uso da altre componenti: Sfruttata da MainActivity. Attività svolte e dati trattati: Visualizza l interfaccia grafica che permette all utente di collegarsi e scollegarsi dal servizio MDTN. Contiene inoltre le informazioni sulle attività recenti (log). Classe MailActivity Tipo, obbiettivo e funzione del componente: Classe che permette l invio di tramite MDTN. Relazioni d uso di altre componenti: Utilizza la classe Message di source.mdtn.util. Interfacce con e relazioni d uso da altre componenti: 70

71 6.2. DEFINIZIONE DEI COMPONENTI Sfruttata da MainActivity. Attività svolte e dati trattati: Visualizza l interfaccia grafica che permette all utente di inviare personalizzate tramite il servizio MDTN. Classe FileActivity Tipo, obbiettivo e funzione del componente: Classe che permette di richiedere e scaricare delle generiche risorse reperibili su Internet. Relazioni d uso di altre componenti: Utilizza la classe GenericResource di source.mdtn.util. Interfacce con e relazioni d uso da altre componenti: Sfruttata da MainActivity. Attività svolte e dati trattati: Visualizza l interfaccia grafica che permette all utente di richiedere e scaricare delle risorse reperibili in Internet attraverso il servizio MDTN Package source.mdtn.server Tipo, obbiettivo e funzione del componente: Il package contiene le classi che costituiscono il server MDTN. Relazioni d uso di altre componenti: Utilizza i package source.mdtn.util, source.mdtn.comm e source.mdtn.bundle. Interfacce con e relazioni d uso da altre componenti: Nessuna. Attività svolte e dati trattati: Le classi qui contenute hanno il compito di implementare il completo funzionamento del server MDTN, ovvero la gestione di tutte le richieste provenienti dagli utenti tramite i rispettivi client Android. 71

72 CAPITOLO 6. PROGETTAZIONE Figura 6.7: Package source.mdtn.server Classe Server Tipo, obbiettivo e funzione del componente: Classe fondamentale che costituisce il server MDTN. Relazioni d uso di altre componenti: Utilizza tutte le classi contenute nel package source.mdtn.server. Interfacce con e relazioni d uso da altre componenti: Nessuna. Attività svolte e dati trattati: Tale classe racchiude la totalità delle componenti che consentono al server MDTN di poter funzionare. La descrizione dettagliata delle varie componenti sarà effettuata nelle rispettive classi specifiche. 72

73 6.2. DEFINIZIONE DEI COMPONENTI Classe CommunicationThread Tipo, obbiettivo e funzione del componente: Questa classe rappresenta una singola connessione con un client. Relazioni d uso di altre componenti: Utilizza il BundleProtocol. Interfacce con e relazioni d uso da altre componenti: La classe Server utilizza oggetti di questa classe per gestire tutte le connessioni con i client. Attività svolte e dati trattati: Si occupa di mantenere e gestire la connessione con un client e di far evolvere la comunicazione in modo corretto adottando il bundle protocol. Classe ServerGui Tipo, obbiettivo e funzione del componente: Classe grafica che fornisce una minima interfaccia al server in modo da poterne monitorare lo stato. Relazioni d uso di altre componenti: Nessuna. Interfacce con e relazioni d uso da altre componenti: La classe Server utilizza tale classe. Attività svolte e dati trattati: Visualizza tutte le informazioni relative allo stato del server e alle rispettive configurazioni attive. Classe Service Tipo, obbiettivo e funzione del componente: Classe di supporto che fornisce alcune funzionalità specifiche di cui il server necessità per poter soddisfare le richieste. Relazioni d uso di altre componenti: 73

74 CAPITOLO 6. PROGETTAZIONE Utilizza tutte le classi del package source.mdtn.util. Interfacce con e relazioni d uso da altre componenti: La classe Server utilizza tale classe. Attività svolte e dati trattati: Si occupa di realizzare effettivamente particolari operazioni (come ad esempio, l invio reale delle ) che sono previste dall iter di esecuzione delle richieste. Classe Dispatcher Tipo, obbiettivo e funzione del componente: Classe dedicata alla programmazione delle attività del Server. Relazioni d uso di altre componenti: Utilizza le classi Executor e Cleaner. Interfacce con e relazioni d uso da altre componenti: La classe Server utilizza tale classe. Attività svolte e dati trattati: Implementa una sorta di dispatcher in grado di selezionare ed avviare le operazioni necessarie a soddisfare le richieste pendenti sul server. Classe Reporter Tipo, obbiettivo e funzione del componente: Classe dedicata alla generazione e consegna delle ricevute. Relazioni d uso di altre componenti: Utilizza le classi del package source.mdtn.bundle e detiene dei riferimenti di tipo CommunicationThread. Interfacce con e relazioni d uso da altre componenti: La classe Server utilizza tale classe. Attività svolte e dati trattati: 74

75 6.2. DEFINIZIONE DEI COMPONENTI Implementa il sistema di consegna delle ricevute di avvenuta esecuzione dei servizi. Si occupa quindi di individuare ed avvisare i client le cui richieste sono state soddisfatte in modo da consentire a quest ultimi di poter accedere alle risorse il prima possibile. Classe Executor Tipo, obbiettivo e funzione del componente: Classe dedicata all esecuzione effettiva delle operazioni che riguardano i servizi. Relazioni d uso di altre componenti: Utilizza la classe Service. Interfacce con e relazioni d uso da altre componenti: La classe Dispatcher utilizza tale classe. Attività svolte e dati trattati: Si occupa di eseguire praticamente le operazioni necessarie a soddisfare un particolare servizio, precedentemente selezionato dal Dispatcher. Classe Cleaner Tipo, obbiettivo e funzione del componente: Classe che funge da garbage collector dell area di storage dei bundle. Relazioni d uso di altre componenti: Nessuna. Interfacce con e relazioni d uso da altre componenti: La classe Dispatcher utilizza tale classe. Attività svolte e dati trattati: Si occupa di eliminare la rappresentazione persistente di un bundle salvato nell area di storage, una volta che questo non è più necessario Package source.mdtn.util Tipo, obbiettivo e funzione del componente: 75

76 CAPITOLO 6. PROGETTAZIONE Figura 6.8: Package source.mdtn.util Il package contiene una serie di classi di generica utilità. Relazioni d uso di altre componenti: Nessuna. Interfacce con e relazioni d uso da altre componenti: Tutti gli altri package sfruttano le classi qui contenute. Attività svolte e dati trattati: Fornisce delle classi di utilità che permettono di evitare le inutili ripetizioni di codice d uso comune e consentono di semplificare alcune operazioni molto frequenti. Classe Buffering Tipo, obbiettivo e funzione del componente: Classe che fornisce alcune funzionalità per l accesso ai file e alla memoria. Relazioni d uso di altre componenti: Nessuna. 76

77 6.2. DEFINIZIONE DEI COMPONENTI Interfacce con e relazioni d uso da altre componenti: Gli altri package utilizzando questa classe. Attività svolte e dati trattati: Fornisce metodi per la scrittura/lettura di file e per la conversione di oggetti in semplici array di byte. Classe Timing Tipo, obbiettivo e funzione del componente: Questa classe contiene alcune funzionalità legate al fattore temporale. Relazioni d uso di altre componenti: Nessuna. Interfacce con e relazioni d uso da altre componenti: Gli altri package utilizzando questa classe. Attività svolte e dati trattati: Fornisce metodi per ottenere data e ora in diversi formati e con diverso livello di dettaglio. Classe Networking Tipo, obbiettivo e funzione del componente: Classe legata alle informazioni della rete e delle relative periferiche. Relazioni d uso di altre componenti: Nessuna. Interfacce con e relazioni d uso da altre componenti: Gli altri package utilizzando questa classe. Attività svolte e dati trattati: Mette a disposizione informazioni sulle interfacce di rete disponibili e sullo stato della connettività Internet. 77

78 CAPITOLO 6. PROGETTAZIONE Classe Message Tipo, obbiettivo e funzione del componente: Classe che rappresenta un generico messaggio . Relazioni d uso di altre componenti: Nessuna. Interfacce con e relazioni d uso da altre componenti: Utilizzata dalle classi MailActivity e Service. Attività svolte e dati trattati: Fornisce una rappresentazione strutturata di un messaggio , fornendo tutti i metodi necessari alla manipolazione ed interpretazione del messaggio. Classe GenericResource Tipo, obbiettivo e funzione del componente: Classe che rappresenta una generica risorsa (un file). Relazioni d uso di altre componenti: Nessuna. Interfacce con e relazioni d uso da altre componenti: Utilizzata dalle classi FileActivity e Service. Attività svolte e dati trattati: Fornisce una rappresentazione strutturata di una generica risorsa o file, fornendo tutti i metodi necessari alla sua gestione ed al suo utilizzo. Classe PolledInputStream Tipo, obbiettivo e funzione del componente: Questa classe rappresenta uno stream personalizzato sensibile ai timeout. Relazioni d uso di altre componenti: Nessuna. 78

79 6.3. PARTICOLARITÀ DEL SERVIZIO Interfacce con e relazioni d uso da altre componenti: Utilizzata dalle classe Service. Attività svolte e dati trattati: Tale classe è l evoluzione del semplice InputStream di Java che permette di impostare un timeout effettivo dopo un tempo di attesa arbitrario. Viene utilizzata per effettuare il download delle risorse da Internet e per accorgersi di possibili problemi di connessione. 6.3 Particolarità del servizio Il servizio di invio non è legato a meccanismi particolarmente complessi o di difficile implementazione. E sufficiente collegarsi ad un server SMTP ed inviare correttamente i dati relativi alle che vogliamo inviare. Tuttavia i normali servizi di invio soffrono di una grossa limitazione, ovvero la restrizione dell accesso ai server di posta in uscita (SMTP) in relazione dell indirizzo IP del richiedente. Non esistono infatti dei server di posta che non siano strettamente legati al provider che ci fornisce la connessione Internet, pertanto risulta impossibile configurare il servizio mail di MDTN utilizzando un unico server di posta. Per come è stato definita l architettura del sistema, avremo dei carrier in continuo movimento che cercheranno di connettersi ad Internet in prossimità di stazioni e fermate. Non possiamo prevedere o in alcun modo vincolare il nostro accesso ad Internet in modo da essere sicuri di poterci collegare ad un server su cui siamo autorizzati ad accedere. Allo stesso tempo risulta complicato ed inefficiente cercare di gestire connessioni a server di posta multipli a seconda della tipologia di indirizzo ip posseduto dal nostro gateway. Per questo motivo è stata adottata una diversa strategia, ossia quella di effettuare l invio delle mail attraverso un web-service. L idea è tanto semplice quanto efficace: installare su un web-server un semplice script PHP richiamabile attraverso una query string appositamente creata sulla base delle informazioni contenute nella mail. Tale script, ricevendo i dati relativi alla , è in grado di concretizzare l invio della mail stessa attraverso un opportuno richiamo della procedura sendmail. In questo modo non ci sono alcune limitazioni relative agli indirizzi ip, in quanto non stiamo facendo altro che una semplice interrogazione ad un web-server, come illustrato in Fig

80 CAPITOLO 6. PROGETTAZIONE Figura 6.9: Invio di un tramite web-service Per quanto concerne l aspetto della sicurezza, questo metodo richiede la presenza di connessioni sicure al web-server (HTTPS) ai fini di garantire la riservatezza delle , nonché la presenza di un minimale sistema di autenticazione che impedisca a terzi di abusare dello script. Si è dunque scelto di adottare questo tipo di tecnica per inviare le del servizio MDTN. Il web-service attualmente utilizzato dal servizio è disponibile all indirizzo lo script è raggiungibile all indirizzo (il sito è ospitato sul portale gratuito Altervista 2 e non comporta alcun costo di mantenimento, anche se purtroppo non supporta HTTPS). 2 Altervista: 80

81 Capitolo 7 Configurazione In questo capitolo verranno presentate le configurazioni necessarie per predisporre ed avviare correttamente un server MDTN. 7.1 Configurazione hardware del server La macchina server che dovrà eseguire il programma server MDTN dovrà essere opportunamente configurata e dovrà essere dotata delle opportune periferiche. In particolare per una configurazione ottimale saranno richieste: due schede di rete (una Ethernet normale e una wireless). un access-point wireless da collegare all interfaccia di rete Ethernet. La scheda di rete wireless sarà usata dal server per cercare di collegarsi alle reti wireless che saranno disponibili nelle fermate e nelle stazioni. Sarà dunque questa periferica a fornire, quando possibile, l accesso ad Internet. Sarà necessario configurare opportunamente il sistema operativo (non ha importanza quale) in modo tale da far collegare automaticamente tale periferica alle reti predefinite. L altra scheda di rete verrà invece usata per collegare al server l accesspoint che si occuperà di fornire il servizio wireless a bordo del carrier. Nella tabella 7.1 vengono fornite le impostazioni standard che dovrebbero essere adottate per configurare un qualsiasi server MDTN. 81

82 CAPITOLO 7. CONFIGURAZIONE Periferica scheda di rete Ethernet access-point wireless. scheda wireless. Setup Indirizzo IP impostato manualmente su Sarà l indirizzo IP di default del server MDTN, a cui i client proveranno a connettersi. DHCP abilitato in modo da assegnare automaticamente gli indirizzi ai client a partire da Va collegato al server tramite cavo Ethernet. Configurata in modo da potersi collegare alle varie reti wireless predefinite in grado di fornire connettività Internet. Tabella 7.1: Configurazione delle periferiche del server 7.2 Avvio e configurazione del server MDTN L applicazione server MDTN si presenta sotto la classica forma di applicazione Java, venendo fornita sia come pacchetto Jar sia come semplice raccolta di classi strutturate (essendo realizzata in Java, non impone particolari vincoli sul sistema operativo da utilizzare). Le modalità di avvio sono quindi quelle classiche delle applicazioni Java. Per avviare il server utilizzando il file Jar, digitare da linea di comando (dopo essersi posizionati nella cartella contenente il file): java -jar ServerMDTN.jar Per avviare il programma correttamente sono richiesti privilegi di amministratore, pertanto potrebbe essere necessario specificare che tale comando venga eseguito con gli opportuni privilegi. Ad esempio, da Ubuntu digi- 82

83 7.2. AVVIO E CONFIGURAZIONE DEL SERVER MDTN tare: sudo java -jar ServerMDTN.jar Tale procedimento è ovviamente automatizzabile attraverso opportuni script di start-up che possono essere configurati (a seconda del sistema operativo utilizzato) in modo da far partire automaticamente l applicazione all avvio della macchina. Per un avvio corretto del server sarà necessario configurare opportunamente il file di configurazione mdtn.config. Tale file deve essere situato nella stessa cartella in cui si trova il file Server- MDTN.jar. Il file di configurazione specifica quali sono i parametri base con cui avviare il server, in mancanza di tale file il server viene avviato con delle impostazioni di default che non ne garantiscono il corretto funzionamento. I parametri configurabili sono i seguenti: Riga 1 - Port: ovvero la porta di comunicazione su cui il server MDTN rimane in attesa di nuovi client (default: 3339). Riga 2 - Bundle storage: specifica quale locazione del file system utilizzare come storage persistente dei bundle (default: la cartella corrente). Riga 3 - Data storage: specifica quale locazione del file system utilizzare come storage delle risorse (default: la cartella corrente). Riga 4 - Max file size: indica qual è la dimensione massima della risorsa richiedibile da un client. File di dimensioni superiori non saranno accettati (default: 15 mb). Riga 5 - Max parallel operation: specifica quante operazioni (intese come istanze di servizi) possono essere eseguite in parallelo dal server. (default: 5 operazioni) In caso di problemi con il file di configurazione viene mostrato un messaggio di errore e il server viene avviato con le impostazioni di default (Fig. 7.1). Figura 7.1: Messaggio di errore durante avvio del server 83

84 CAPITOLO 7. CONFIGURAZIONE A questo punto il server MDTN è attivo e pronto a funzionare (Fig. 7.2). Non sono richiesti ulteriori particolari interventi in quanto l intero funzionamento è automatizzato. Figura 7.2: Schermata del server MDTN Vengono ad ogni modo fornite delle informazioni di base per poter monitorare lo stato e le attività in esecuzione, al fine di individuare eventuali malfunzionamenti. Avremo a disposizione le seguenti informazioni: Indirizzo IP della periferica di rete usata per la connessione Internet. Stato della connessione Internet. Numero di client collegati. Log degli eventi e delle attività. Una volta avviato, il servizio del server MDTN può essere arrestato solamente terminando l applicazione. 84

85 Capitolo 8 Testing In questo capitolo presenteremo il resoconto della fase di testing e collaudo del sistema MDTN, ponendo particolare enfasi sugli aspetti più interessanti e sui problemi emersi durante lo svolgimento di tale attività. 8.1 Dotazione e ambiente di lavoro Ai fini di consentire sviluppo e testing del progetto sono state fornite dall Università alcune attrezzature fondamentali, senza le quali non sarebbe stato possibile lavorare. I mezzi e le risorse messi a disposizione sono stati i seguenti: Laboratorio Tesisti come luogo di lavoro e di confronto, caratterizzato dalla presenza di una connessione Internet ad alta velocità e da macchine e monitor liberamente utilizzabili. un HTC Hero operante con la versione 1.5 di Android. una rete wireless dedicata, denominata LabInf, erogata da un access-point Netgear situato nella sala server per gentile concessione dei sistemisti. Per quanto riguarda i mezzi propri utilizzati ci si è serviti sostanzialmente del proprio computer portatile. In aggiunta, grazie alla disponibilità di alcuni colleghi del laboratorio, è stato possibile utilizzare ulteriori dispositivi HTC operanti con Android 2.1 (HTC Evo e HTC Desire) per gentile concessione degli stessi. 85

86 CAPITOLO 8. TESTING Le operazioni di sviluppo e testing del servizio, così come il collaudo finale, sono state effettuate quasi nella loro totalità all interno del Laboratorio Informatico Tesisti Test delle singole componenti La verifica del corretto funzionamento delle singole componenti del sistema è stata sostenuta durante l intero ciclo di sviluppo, sia attraverso l utilizzo di tecniche di analisi statica (es: verifica del codice con inspection) che dinamica (es: test di sistema). Alcune funzionalità caratteristiche hanno richiesto particolare attenzione in quanto non era sufficiente testarne semplicemente il corretto funzionamento, ma era necessario verificarne il comportamento sottoponendole a carichi di lavoro (relativamente) elevati. Gli elementi più interessanti, ovvero quelli che hanno portato all individuazione di problemi o errori, sono stati i seguenti: Dispatcher: tale componente, dovendo gestire i task relativi alle operazioni necessarie a soddisfare le richieste, è fortemente influenzato dal carico di lavoro, inteso come numero di richieste pendenti. Per evitare possibili collassi del sistema è stato implementato un meccanismo di gestione dei task in modo tale da limitare il numero di operazioni da eseguire contemporaneamente (tale numero è definibile tramite la configurazione del server MDTN). La soluzione adottata si è dimostrata idonea a prevenire potenziali crash del sistema (è stata testata con oltre 500 richieste pendenti più o meno complesse), tuttavia soffre di un inefficienza di fondo dovuta al fatto che il numero di processi sostenibili non varia dinamicamente in base al carico del server e alla disponibilità di risorse. L implementazione di un auto-tune è stata considerata troppo dispendiosa in termini di risorse, ma costituisce un potenziale miglioramento futuro. Invio strettamente correlato al problema dell alto numero di richieste pendenti, ha presentato parecchi problemi in situazioni particolari in cui era necessario inviare moltissime . Il problema riscontrato è stato che il web-service utilizzato non permetteva l esecuzione di un numero così alto di richieste (si presume a fronte di evitare abusi e spam), pertanto occasionalmente fallivano intere sequenze di operazioni di invio mail. Per risolvere il problema è stato introdotto un riscontro, al termine della chiamata allo script remoto, in modo da determinare eventuali errori e quindi

87 8.3. COLLAUDO ri-schedulare l operazione. Sono stati effettuati con successo dei test con un carico di lavoro di circa ciascuno. Downloader: il download di risorse da Internet in condizioni di connettività precaria ha presentato ovviamente delle difficoltà. Come specificato in fase di progettazione è stato sviluppato un particolare tipo di stream (PolledInputStream) in grado di gestire in modo personalizzato i timeout a livello applicazione e di individuare così eventuali problemi di connessione. Sono stati effettuati diversi test con file di dimensioni varie (fino ad 1gb), provando ad alterare la connettività e verificando il comportamento del programma. Il sistema ha risposto correttamente ai vari test, rischedulando opportunamente le richieste non portate a termine a causa dei problemi legati alla connessione. Persistenza: Per verificare la robustezza del sistema Store-And-Forward con persistenza sono stati effettuati dei test mirati in cui il server veniva inibito improvvisamente attraverso terminazioni forzate del programma e reset della macchina stessa. Al riavvio del servizio lo storage persistente ha sempre permesso di ripristinare il lavoro in modo corretto e coerente. 8.3 Collaudo Non potendo implementare realmente lo scenario di utilizzo specificato nelle pagine di introduzione ed analisi si è dovuto ricorre all utilizzo di uno scenario di collaudo diverso, una sorta di simulazione dello scenario reale. Grazie ai locali e alle attrezzature messe a disposizione è stato possibile realizzare una piccola infrastruttura di rete che, seppur tecnicamente differente da quella dello scenario reale, presentasse le stesse caratteristiche e le stesse problematiche. Lo scenario è stato così impostato: carrier e server MDTN : questo ruolo è stato interpretato dal computer portatile. Tale macchina disponeva di due tipi di connettività: quella Internet, costituita da un collegamento cablato alla rete, e quella wireless collegata all access-point della rete LabInf. Tale rete costituiva dunque la connettività wireless del servizio del carrier, ovvero la connessione messa a disposizione dei client. La macchina eseguiva ovviamente l applicazione server MDTN. clients MDTN : i vari client sono stati interpretati da diversi dispositivi HTC operanti con Android (versione 1.5 e 2.1) e dall emulatore interno dell SDK Android. Erano presenti quindi sia device fisici che virtuali, in un numero 87

88 CAPITOLO 8. TESTING complessivo mai superiore a 5 (per ovvia mancanza di ulteriori dispositivi). Su ogni client è stata installata ed avviata l applicazione client MDTN. Il compito dei vari client era quello di utilizzare il servizio, ovvero effettuare continuamente connessioni/disconnessioni e richieste al server in modo autonomo e pseudocasuale. Il server aveva ovviamente il compito di gestire il carico di lavoro e di rispondere correttamente alle manomissioni volontarie effettuate dall esterno ai fini di simulare le possibili condizioni dello scenario reale. Tali manomissioni consistevano fondamentalmente in disconnessioni forzate della rete Internet (hard-reset) realizzate staccando fisicamente i cavi in modo da simulare la perdita della connessione Internet wireless del carrier e in spegnimenti forzati del server stesso, con lo scopo di verificare la robustezza del sistema Store-And-Forward con memorizzazione persistente. Il sistema è stato collaudato secondo queste modalità per diverse volte (in scala ridotta, anche in presenza del proponente e del tutor interno) ed ha sempre risposto correttamente alle aspettative. Si ritiene dunque che sia pronto per una prima sperimentazione diretta sul campo. 88

89 Capitolo 9 Conclusioni L attività di stage interno si è conclusa soddisfando la totalità dei requisiti obbligatori e desiderabili entro i tempi previsti. Non è stato invece possibile soddisfare nella loro totalità i requisiti opzionali per mancanza di tempo e risorse. Tra i requisiti opzionali è stato implementato il sistema di condivisione delle risorse pubbliche mediante la cosiddetta bacheca pubblica, mentre non è stato possibile implementare il sistema di gestione dei gruppi di utenti e la modalità estesa del servizio (vedi 5.2). Per quanto riguarda quest ultimo punto, nonostante la mancanza di un implementazione effettiva sono stati predisposti i componenti necessari per permetterne un futuro sviluppo e sono state individuate delle possibili soluzioni architetturali da adottare ai fini di un effettiva realizzazione (vedi sezione 9.2). 9.1 Consuntivo Riportiamo il consuntivo delle ore effettivamente svolte nelle varie attività, confrontate con le ore preventivate (Fig. 9.1). Su un preventivo di 325 ore sono state effettivamente utilizzate 337 ore. Come si può vedere dal grafico, la fasi di progettazione e testing sono state sottostimate, ma per fortuna sono state bilanciate dalle fasi di analisi e realizzazione, precedentemente sovrastimate in fase di stesura del piano di lavoro. 9.2 Sviluppi futuri Il prossimo step del progetto è sicuramente quello di implementare la modalità estesa ai fini di fornire un servizio più efficace e versatile agli 89

90 CAPITOLO 9. CONCLUSIONI Figura 9.1: Confronto preventivo-consuntivo ore. utenti. Sono state individuate due possibili soluzioni architetturali per implementare questa modalità: soluzione centralizzata: in questa soluzione è previsto l inserimento di un nuovo componente all interno dell architettura della rete, ovvero un router MDTN. Tale componente dovrebbe essere posizionato in prossimità dei capolinea comuni dei mezzi di trasporto (es: stazione centrale, deposito) e si dovrebbe occupare di raccogliere e distribuire le informazioni (sempre in forma di bundles) ai vari carrier in modo da consentire a quest ultimi di recuperare e mettere a disposizione risorse che non sono state richieste direttamente sul carrier in questione ma bensì da un altro. In questo modo un utente potrebbe richiedere una risorsa e specificare su quale carrier (ovvero su quale linea di autobus) renderla disponibile. distribuita: in questa soluzione non è prevista la presenza di un entità centralizzante. Al contrario, ogni carrier ha il compito di gestire in modo autonomo il processo di routing basandosi su un approccio comunicativo che unisce le tecniche di comunicazione occasionale e programmata (accennate 90

91 9.3. POSSIBILITÀ D USO DEL PRODOTTO nella sezione 2.2.2). L idea per realizzare questo tipo di soluzione consiste nel dotare ogni carrier di un dispositivo GPS in grado di individuare la posizione del mezzo all interno della rete di trasporti. Confrontando la posizione attuale del mezzo in una particolare tabella contenente informazioni sulle varie linee di trasporti, con le relative posizioni ed orari, sarebbe possibile stabilire quali sono i carriers con cui un dato carrier può potenzialmente entrare in contatto e quindi in base a queste informazioni prevedere gli opportuni routing. In questo caso sarebbero i carriers stessi a comunicare tra loro, limitandosi ad inoltrare in modo opportuno i bundle contenenti richieste di risorse al carrier giusto. Ulteriori sviluppi potrebbero consistere nella realizzazione di client compatibili per diverse altre piattaforme (es: Symbian OS 1 ), in quanto il core del servizio MDTN è realizzato in puro linguaggio Java ed è racchiuso in un unico semplice componente importabile in qualsiasi applicazione. 9.3 Possibilità d uso del prodotto Allo stadio attuale il prodotto può essere utilizzato in via sperimentale per fornire un servizio basilare di invio e download di file, con le limitazioni caratteristiche dello scenario di utilizzo di base. Se implementato in modalità estesa tale servizio potrebbe essere realmente utilizzabile in scenari reali come città e paesi. Potrebbe anche essere utilizzato per fornire servizi Internet di base in zone rurali occasionalmente raggiunte da autobus (o da altri mezzi in grado di ricoprire il ruolo di carrier) a costi estremamente bassi Preventivo di installazione E stato calcolato un preventivo, puramente ipotetico, per stimare il costo di attuazione del progetto in una città come Padova. Fondamentalmente tutti i costi sono incentrati sulle attrezzature necessarie a trasformare i normali mezzi pubblici in veri e propri carrier. Il costo di un server MDTN dedicato è stato stimato attorno ai 192e così suddivisi: 94e: sistema base con processore 1.6Ghz X2 Intel Dual Core Atom System, VGA, LAN, 6 USB, DDR2, SATA, SSD, wireless. 1 Symbian OS: 91

92 CAPITOLO 9. CONCLUSIONI 28e: due banchi di Ram CORSAIR VS1GB667D2 DDR2 1GB(667Mhz). 33e: HARD DISK Western Digital SATA2 1,5TB (64MB Cache, 7200RPM) 20e: sistema di alimentazione. 17e: access-point TP-LINK TL-WA500G (54Mbit IEEE802.11g). 0e: sistema operativo Linux. I prezzi ovviamente sono indicativi, in quanto un acquisto in stock porta sicuramente ad avere degli sconti anche consistenti. Consideriamo ora l azienda che gestisce il trasporto pubblico padovano: l APS Holding 2. Quest ultima fornisce un resoconto (aggiornato al 2007) in cui elenca una serie di statistiche interessanti in merito alla propria flotta di automezzi e al traffico di passeggeri. Dai dati ufficiali risulta che la flotta di automezzi ammonta a 260 unità (comprendenti mezzi urbani, extraurbani e speciali). Ipotizzando di installare il servizio MDTN su tutti gli automezzi avremmo un costo complessivo di e in attrezzature. A questi soldi vanno poi aggiunti i costi di installazione, che possiamo stimare intorno ai 32e per unità. Il totale teorico ammonta quindi a e. Pur avendo coscienza di aver eseguito un esercizio di calcolo estremamente ingenuo e approssimativo, siamo comunque in grado di inquadrare l ordine di grandezza del costo di attuazione. Con questi soldi saremmo teoricamente in grado di predisporre e successivamente erogare il servizio MDTN su un area geografica estesa lungo 300 Km di tratte stradali frequentate ogni anno da oltre 36 milioni di passeggeri (dati ufficiali APS holding). 9.4 Considerazioni personali L attività di stage ha sicuramente accresciuto le mie competenze teoriche e professionali permettendomi di entrare nel mondo dello sviluppo di applicazioni mobile e di ampliare le conoscenze nel campo delle reti. Andando oltre l aspetto del puro accrescimento di competenze posso dire che quest esperienza si è dimostrata particolarmente stimolante in quanto mi ha permesso di esplorare un ramo delle telecomunicazioni relativamente poco conosciuto e di andare a realizzare un qualcosa di nuovo, con la 2 APS holding: 92

93 9.4. CONSIDERAZIONI PERSONALI speranza che (anche in un futuro prossimo) possa essere liberamente utilizzata e essere d aiuto per qualcuno. Ringraziamenti Il primo ringraziamento va senz altro al mio relatore, il prof. Claudio Enrico Palazzi, per la sua costante disponibilità e per avermi offerto l opportunità di intraprendere questo progetto. Un grazie alla mia famiglia che da sempre mi supporta sia moralmente che economicamente. Un saluto e un ringraziamento va agli amici ed ai compagni d avventura con i quali ho condiviso i momenti più belli e più duri di questi ultimi anni, senza di loro non sarebbe stato lo stesso. Mi risparmio la classica frase di circostanza non sto qui ad elencarvi tutti uno ad uno per paura di dimenticarmi qualcuno in quanto mi ricordo benissimo di tutti voi, semplicemente mi sembra di aver già scritto abbastanza in questa tesi! 93

94 CAPITOLO 9. CONCLUSIONI 94

95 Appendice A Manuale del client MDTN A.1 Installazione dell applicazione La procedura di installazione del client MDTN è esattamente identica a quella usata per le normali applicazioni di Android. Nel caso in cui si disponga già del file dell applicazione (MDTN.apk), è possibile installarlo direttamente utilizzando il proprio manager delle applicazioni preferito. Nel caso non si disponga del file, è possibile scaricarlo direttamente tramite il browser predefinito all indirizzo apk, dove troveremo sempre l ultima versione disponibile del programma. Per funzionare correttamente, l applicazione richiede una serie di privilegi che dovremo concedere in fase di installazione (Fig. A.1). Figura A.1: Installazione del client MDTN Una volta installata l applicazione è pronta per l uso e potrà essere avviata secondo le modalità usuali di Android. 95

96 APPENDICE A. MANUALE DEL CLIENT MDTN A.2 Utilizzo A.2.1 Schermata iniziale Una volta avviato il programma si presenta con una schermata composta da tab selezionabili, le quali permettono di accedere alle varie funzionalità. Avremo la tab Info (Fig. A.2) contenente una serie di informazioni sul programma, la tab Status che gestisce e monitora la connessione al servizio, la tab che permette di accedere alla funzionalità di invio e la tab Files che richiama la gestione delle risorse. Figura A.2: Schermata di avvio. A.2.2 Connessione al servizio Per poter utilizzare le funzionalità messe a disposizione è necessario innanzitutto collegarsi al servizio. Selezionando la tab Status accederemo alla schermata di connessione dalla quale potremo vedere lo stato della connessione Wi-Fi e del servizio MDTN. Se non si è già collegati alla rete wireless del carrier (Fig. A.3), allora prima di tutto sarà necessario connettersi con il Wi-Fi alla suddetta rete tramite il gestore delle reti wireless (il nome della rete wireless solitamente è MDTN service, ma potrebbe anche essere diverso a seconda delle configurazioni effettuate). A questo punto è possibile effettuare la connessione vera e propria al servizio MDTN. E possibile specificare un indirizzo del server MDTN (nel 96

97 A.2. UTILIZZO Figura A.3: Nessun collegamento Wi-Fi. caso questo sia stato configurato con parametri diversi da quelli di default). Selezionando il pulsante Connetti MDTN avvieremo la connessione al servizio (Fig. A.4). Figura A.4: Connessione al servizio. In caso di successo, lo stato del servizio MDTN verrà impostato a Connesso e sarà possibile iniziare ad utilizzare le varie funzionalità. In caso di problemi o errori di connessione sarà necessario rivedere i passi precedenti e riprovare. 97

98 A.2.3 Invio di APPENDICE A. MANUALE DEL CLIENT MDTN Selezionando la tab sarà possibile accedere alla relativa schermata. Dopo aver compilato i vari campi si potrà specificare se si desidera ricevere un di conferma di avvenuta spedizione del messaggio all indirizzo del mittente attraverso l apposita check box posizionata al di sopra del pulsante di invio. Per inviare l a questo punto è sufficiente premere il pulsante Invia . Un messaggio di conferma notificherà il corretto inoltro dell al servizio (Fig. A.5). Figura A.5: Invio di un . Il servizio MDTN notificherà comunque l invio dell (una volta che questo è stato effettivamente effettuato) attraverso una notifica che verrà visualizzata nella status bar (Fig. A.6). Nel momento stesso in cui riceveremo questa notifica saremo sicuri che l è stata realmente inviata. Figura A.6: Notifica dell invio effettivo dell . 98

99 A.2. UTILIZZO A.2.4 Richiesta e gestione delle risorse Attraverso la tab Files accederemo alla gestione dei files e delle risorse. La schermata metterà a disposizione cinque pulsanti grafici che permetteranno di: richiedere nuove risorse, accedere alle risorse locali del telefono, alle risorse remote disponibili sul server, alle risorse disponibili nella bacheca pubblica e infine effettuare la sincronizzazione (ovvero l aggiornamento delle liste delle risorse). Effettuando richiesta per una nuova risorsa (Fig. A.8) ci verrà richiesto di inserire l indirizzo (URL) da cui poterla scaricare e potremo esprimere la nostra preferenza in merito alla visibilità di quest ultima: saremo quindi in grado di stabilire se renderla Schermata ge- Figura A.7: stione files. pubblica (ovvero reperibile dalla bacheca pubblica) oppure se mantenerla privata. Figura A.8: Richiesta di una nuova risorsa. Anche questa operazione (come l invio delle ) verrà notificata una volta portate a termine. Potrebbe capitare però che la risorsa specificata non esista, oppure che sia eccessivamente grande (le dimensioni massime 99

100 APPENDICE A. MANUALE DEL CLIENT MDTN sono legate alle impostazioni del server MDTN): in tal caso riceveremo degli opportuni messaggi di notifica (Fig. A.9). Figura A.9: Fallimento di una richiesta: risorsa inesistente o troppo grande. Se la risorsa è invece stata scaricata correttamente riceveremo una notifica che ci informa del fatto che è finalmente disponibile per essere scaricata dalla nostra area remota direttamente sul telefono. A quel punto dovremo effettuare una sincronizzazione in modo da aggiornare le nostre liste delle risorse (Fig. A.10), spostarci nella lista delle risorse remote e scaricare il file. Figura A.10: Sincronizzazione. 100

101 A.2. UTILIZZO La procedura per scaricare un file dall area remota (o dalla bacheca pubblica) al telefono è molto semplice. Una volta posizionati nella lista delle risorse remote sarà sufficiente selezionare la risorsa che ci interessa e richiederne il download (Fig. A.11). Con la stessa procedura sarà inoltre possibile eliminare le risorse di cui non abbiamo più bisogno. Figura A.11: Download di una risorsa. Durante il download della risorsa potremo costantemente monitorare lo stato di avanzamento dell operazione grazie alla presenza di un messaggio di stato che indicherà la percentuale di completamento, anche durante l esecuzione di altre attività (Fig. A.12). Una volta terminato il download la risorsa sarà disponibile tra le risorse locali del telefono e potrà essere utilizzata a discrezione dell utente. Figura A.12: Avanzamento del download e completamento. 101

Lo scenario: la definizione di Internet

Lo scenario: la definizione di Internet 1 Lo scenario: la definizione di Internet INTERNET E UN INSIEME DI RETI DI COMPUTER INTERCONNESSE TRA LORO SIA FISICAMENTE (LINEE DI COMUNICAZIONE) SIA LOGICAMENTE (PROTOCOLLI DI COMUNICAZIONE SPECIALIZZATI)

Dettagli

Reti di Telecomunicazione Lezione 8

Reti di Telecomunicazione Lezione 8 Reti di Telecomunicazione Lezione 8 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Livello di trasporto Programma della lezione relazione tra lo strato di trasporto e lo strato

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Parte II Lezione 5

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Parte II Lezione 5 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II Lezione 5 Giovedì 19-03-2015 1 Intensità del traffico e perdita dei pacchetti La componente

Dettagli

Reti di Calcolatori. Il software

Reti di Calcolatori. Il software Reti di Calcolatori Il software Lo Stack Protocollare Application: supporta le applicazioni che usano la rete; Transport: trasferimento dati tra host; Network: instradamento (routing) di datagram dalla

Dettagli

MANUALE D'USO DEL PROGRAMMA IMMOBIPHONE

MANUALE D'USO DEL PROGRAMMA IMMOBIPHONE 1/6 MANUALE D'USO DEL PROGRAMMA IMMOBIPHONE Per prima cosa si ringrazia per aver scelto ImmobiPhone e per aver dato fiducia al suo autore. Il presente documento istruisce l'utilizzatore sull'uso del programma

Dettagli

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione I semestre 04/05 Comunicazione tra Computer Protocolli Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica 1

Dettagli

Reti di Telecomunicazione Lezione 6

Reti di Telecomunicazione Lezione 6 Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server

Dettagli

NAVIGAORA HOTSPOT. Manuale utente per la configurazione

NAVIGAORA HOTSPOT. Manuale utente per la configurazione NAVIGAORA HOTSPOT Manuale utente per la configurazione NAVIGAORA Hotspot è l innovativo servizio che offre ai suoi clienti accesso ad Internet gratuito, in modo semplice e veloce, grazie al collegamento

Dettagli

Hardware delle reti LAN

Hardware delle reti LAN Hardware delle reti LAN Le reti LAN utilizzano una struttura basata su cavi e concentratori che permette il trasferimento di informazioni. In un ottica di questo tipo, i computer che prendono parte allo

Dettagli

MODELLO CLIENT/SERVER. Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it

MODELLO CLIENT/SERVER. Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it MODELLO CLIENT/SERVER Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it POSSIBILI STRUTTURE DEL SISTEMA INFORMATIVO La struttura di un sistema informativo

Dettagli

Registratori di Cassa

Registratori di Cassa modulo Registratori di Cassa Interfacciamento con Registratore di Cassa RCH Nucleo@light GDO BREVE GUIDA ( su logiche di funzionamento e modalità d uso ) www.impresa24.ilsole24ore.com 1 Sommario Introduzione...

Dettagli

La VPN con il FRITZ!Box Parte I. La VPN con il FRITZ!Box Parte I

La VPN con il FRITZ!Box Parte I. La VPN con il FRITZ!Box Parte I La VPN con il FRITZ!Box Parte I 1 Introduzione In questa mini-guida illustreremo come realizzare un collegamento tramite VPN(Virtual Private Network) tra due FRITZ!Box, in modo da mettere in comunicazioni

Dettagli

Network Monitoring. Introduzione all attività di Network Monitoring introduzione a Nagios come motore ideale

Network Monitoring. Introduzione all attività di Network Monitoring introduzione a Nagios come motore ideale Network Monitoring & Introduzione all attività di Network Monitoring introduzione a Nagios come motore ideale Nicholas Pocher Poker SpA - Settimo Torinese, Novembre 2013 1 Indice Il Network Monitoring:

Dettagli

Creare una Rete Locale Lezione n. 1

Creare una Rete Locale Lezione n. 1 Le Reti Locali Introduzione Le Reti Locali indicate anche come LAN (Local Area Network), sono il punto d appoggio su cui si fonda la collaborazione nel lavoro in qualunque realtà, sia essa un azienda,

Dettagli

Scuola Professionale e Filologica Geom. F.Borgogna Vercelli

Scuola Professionale e Filologica Geom. F.Borgogna Vercelli Scuola Professionale e Filologica Geom. F.Borgogna Vercelli Corsi ANDROID 2013/2014 Benvenuti nel mondo dinamico dello sviluppo di applicazioni per smartphone e tablet Android Corsi ANDROID 2013/2014 L

Dettagli

esales Forza Ordini per Abbigliamento

esales Forza Ordini per Abbigliamento esales Rel. 2012 Forza Ordini per Abbigliamento Scopo di questo documento è fornire la descrizione di una piattaforma di Raccolta Ordini via Web e la successiva loro elaborazione in ambiente ERP Aziendale.

Dettagli

FRITZ!WLAN Repeater 300E. Come estendere la copertura della rete Wi-Fi

FRITZ!WLAN Repeater 300E. Come estendere la copertura della rete Wi-Fi Come estendere la copertura della rete Wi-Fi 1 Introduzione La crescente diffusione di dispositivi portatili per il collegamento ad Internet ha reso la connettività senza fili una caratteristica imprescindibile

Dettagli

1) GESTIONE DELLE POSTAZIONI REMOTE

1) GESTIONE DELLE POSTAZIONI REMOTE IMPORTAZIONE ESPORTAZIONE DATI VIA FTP Per FTP ( FILE TRANSFER PROTOCOL) si intende il protocollo di internet che permette di trasferire documenti di qualsiasi tipo tra siti differenti. Per l utilizzo

Dettagli

PARTE 1 richiami. SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet )

PARTE 1 richiami. SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet ) PARTE 1 richiami SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet ) Parte 1 Modulo 1: Stack TCP/IP TCP/IP Protocol Stack (standard de facto) Basato su 5 livelli invece che sui 7 dello stack ISO/OSI Application

Dettagli

Il fenomeno della geolocalizzazione. Ugo Benini

Il fenomeno della geolocalizzazione. Ugo Benini Il fenomeno della geolocalizzazione Ugo Benini pagina 1 di 9 Cos è la geolocalizzazione Come si è evoluto il concetto di geolocalizzazione negli ultimi anni? Quali le ricadute nel mondo dei Social Network?

Dettagli

Reti di Telecomunicazioni Mobile IP Mobile IP Internet Internet Protocol header IPv4 router host indirizzi IP, DNS URL indirizzo di rete

Reti di Telecomunicazioni Mobile IP Mobile IP Internet Internet Protocol header IPv4 router host indirizzi IP, DNS URL indirizzo di rete IP Analizziamo con sufficiente dettaglio il sistema denominato IP, usato per consentire a due computer mobili di spostarsi liberamente in altre reti pur mantenendo lo stesso indirizzo IP. In particolare,

Dettagli

Reti di calcolatori ed indirizzi IP

Reti di calcolatori ed indirizzi IP ITIS TASSINARI, 1D Reti di calcolatori ed indirizzi IP Prof. Pasquale De Michele 5 aprile 2014 1 INTRODUZIONE ALLE RETI DI CALCOLATORI Cosa è una rete di calcolatori? Il modo migliore per capire di cosa

Dettagli

Software di sistema e software applicativo. I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche

Software di sistema e software applicativo. I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche Software di sistema e software applicativo I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche Software soft ware soffice componente è la parte logica

Dettagli

Tecniche di progettazione e sviluppo di applicazioni mobile

Tecniche di progettazione e sviluppo di applicazioni mobile Slide del corso FSE Tecniche di progettazione e sviluppo di applicazioni mobile svolto presso AREA Science Park Padriciano - Trieste - Italy diegozabot@yahoo.it Android Introduzione diegozabot@yahoo.it

Dettagli

MANUALE MOODLE STUDENTI. Accesso al Materiale Didattico

MANUALE MOODLE STUDENTI. Accesso al Materiale Didattico MANUALE MOODLE STUDENTI Accesso al Materiale Didattico 1 INDICE 1. INTRODUZIONE ALLA PIATTAFORMA MOODLE... 3 1.1. Corso Moodle... 4 2. ACCESSO ALLA PIATTAFORMA... 7 2.1. Accesso diretto alla piattaforma...

Dettagli

Introduzione. Classificazione di Flynn... 2 Macchine a pipeline... 3 Macchine vettoriali e Array Processor... 4 Macchine MIMD... 6

Introduzione. Classificazione di Flynn... 2 Macchine a pipeline... 3 Macchine vettoriali e Array Processor... 4 Macchine MIMD... 6 Appunti di Calcolatori Elettronici Esecuzione di istruzioni in parallelo Introduzione... 1 Classificazione di Flynn... 2 Macchine a pipeline... 3 Macchine vettoriali e Array Processor... 4 Macchine MIMD...

Dettagli

Dispensa di Informatica I.1

Dispensa di Informatica I.1 IL COMPUTER: CONCETTI GENERALI Il Computer (o elaboratore) è un insieme di dispositivi di diversa natura in grado di acquisire dall'esterno dati e algoritmi e produrre in uscita i risultati dell'elaborazione.

Dettagli

Architetture Applicative

Architetture Applicative Alessandro Martinelli alessandro.martinelli@unipv.it 6 Marzo 2012 Architetture Architetture Applicative Introduzione Alcuni esempi di Architetture Applicative Architetture con più Applicazioni Architetture

Dettagli

Allegato 3 Sistema per l interscambio dei dati (SID)

Allegato 3 Sistema per l interscambio dei dati (SID) Sistema per l interscambio dei dati (SID) Specifiche dell infrastruttura per la trasmissione delle Comunicazioni previste dall art. 11 comma 2 del decreto legge 6 dicembre 2011 n.201 Sommario Introduzione...

Dettagli

NOTE OPERATIVE. Prodotto Inaz Download Manager. Release 1.3.0

NOTE OPERATIVE. Prodotto Inaz Download Manager. Release 1.3.0 Prodotto Inaz Download Manager Release 1.3.0 Tipo release COMPLETA RIEPILOGO ARGOMENTI 1. Introduzione... 2 2. Architettura... 3 3. Configurazione... 4 3.1 Parametri di connessione a Internet... 4 3.2

Dettagli

Corso di Sistemi di Elaborazione delle informazioni. Reti di calcolatori 2 a lezione a.a. 2009/2010 Francesco Fontanella

Corso di Sistemi di Elaborazione delle informazioni. Reti di calcolatori 2 a lezione a.a. 2009/2010 Francesco Fontanella Corso di Sistemi di Elaborazione delle informazioni Reti di calcolatori 2 a lezione a.a. 2009/2010 Francesco Fontanella Una definizione di Rete Una moderna rete di calcolatori può essere definita come:

Dettagli

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati Affidabilità nel servizio precisione negli strumenti Chanda LPR Chanda LPR è una piattaforma

Dettagli

Software di gestione della stampante

Software di gestione della stampante Questo argomento include le seguenti sezioni: "Uso del software CentreWare" a pagina 3-11 "Uso delle funzioni di gestione della stampante" a pagina 3-13 Uso del software CentreWare CentreWare Internet

Dettagli

Guida alla registrazione on-line di un DataLogger

Guida alla registrazione on-line di un DataLogger NovaProject s.r.l. Guida alla registrazione on-line di un DataLogger Revisione 3.0 3/08/2010 Partita IVA / Codice Fiscale: 03034090542 pag. 1 di 17 Contenuti Il presente documento è una guida all accesso

Dettagli

Dal protocollo IP ai livelli superiori

Dal protocollo IP ai livelli superiori Dal protocollo IP ai livelli superiori Prof. Enrico Terrone A. S: 2008/09 Protocollo IP Abbiamo visto che il protocollo IP opera al livello di rete definendo indirizzi a 32 bit detti indirizzi IP che permettono

Dettagli

Guida Compilazione Piani di Studio on-line

Guida Compilazione Piani di Studio on-line Guida Compilazione Piani di Studio on-line SIA (Sistemi Informativi d Ateneo) Visualizzazione e presentazione piani di studio ordinamento 509 e 270 Università della Calabria (Unità organizzativa complessa-

Dettagli

LA GESTIONE DELLE VISITE CLIENTI VIA WEB

LA GESTIONE DELLE VISITE CLIENTI VIA WEB LA GESTIONE DELLE VISITE CLIENTI VIA WEB L applicazione realizzata ha lo scopo di consentire agli agenti l inserimento via web dei dati relativi alle visite effettuate alla clientela. I requisiti informatici

Dettagli

30 giorni di prova gratuiti, entra nel sito www.mypckey.com scarica e installa subito mypckey

30 giorni di prova gratuiti, entra nel sito www.mypckey.com scarica e installa subito mypckey DA OGGI NON IMPORTA DOVE SEI, IL TUO PC DELL UFFICIO E SEMPRE A TUA DISPOSIZIONE! Installa solo un semplice programma (nessun hardware necessario!), genera la tua chiavetta USB, e sei pronto a prendere

Dettagli

Informatica per la comunicazione" - lezione 8 -

Informatica per la comunicazione - lezione 8 - Informatica per la comunicazione - lezione 8 - I multipli 1 KB (kilo) = 1000 B 1 MB (mega) = 1 mln B 1 GB (giga) = 1 mld B 1 TB (tera) = 1000 mld B Codifica binaria dei numeri Numerazione con base 10:

Dettagli

Consiglio regionale della Toscana. Regole per il corretto funzionamento della posta elettronica

Consiglio regionale della Toscana. Regole per il corretto funzionamento della posta elettronica Consiglio regionale della Toscana Regole per il corretto funzionamento della posta elettronica A cura dell Ufficio Informatica Maggio 2006 Indice 1. Regole di utilizzo della posta elettronica... 3 2. Controllo

Dettagli

Titolare del trattamento dei dati innanzi descritto è tsnpalombara.it

Titolare del trattamento dei dati innanzi descritto è tsnpalombara.it Decreto Legislativo 196/2003 Codice in materia di protezione dei dati personali COOKIE POLICY La presente informativa è resa anche ai sensi dell art. 13 del D.Lgs 196/03 Codice in materia di protezione

Dettagli

Replica con TeraStation 3000/4000/5000/7000. Buffalo Technology

Replica con TeraStation 3000/4000/5000/7000. Buffalo Technology Replica con TeraStation 3000/4000/5000/7000 Buffalo Technology Introduzione La funzione di replica consente di sincronizzare una cartella in due diversi dispositivi TeraStation quasi in tempo reale. Il

Dettagli

Manuale d'uso. Manuale d'uso... 1. Primo utilizzo... 2. Generale... 2. Gestione conti... 3. Indici di fatturazione... 3. Aliquote...

Manuale d'uso. Manuale d'uso... 1. Primo utilizzo... 2. Generale... 2. Gestione conti... 3. Indici di fatturazione... 3. Aliquote... Manuale d'uso Sommario Manuale d'uso... 1 Primo utilizzo... 2 Generale... 2 Gestione conti... 3 Indici di fatturazione... 3 Aliquote... 4 Categorie di prodotti... 5 Prodotti... 5 Clienti... 6 Fornitori...

Dettagli

La Videosorveglianza Criteri per il dimensionamento dello storage

La Videosorveglianza Criteri per il dimensionamento dello storage La Videosorveglianza Criteri per il dimensionamento dello storage Serie vol 1005/2010 L importanza di registrare le immagini video Il valore di un sistema di videosorveglianza non dipende solo dall abilità

Dettagli

BMSO1001. Virtual Configurator. Istruzioni d uso 02/10-01 PC

BMSO1001. Virtual Configurator. Istruzioni d uso 02/10-01 PC BMSO1001 Virtual Configurator Istruzioni d uso 02/10-01 PC 2 Virtual Configurator Istruzioni d uso Indice 1. Requisiti Hardware e Software 4 1.1 Requisiti Hardware 4 1.2 Requisiti Software 4 2. Concetti

Dettagli

Interfaccia KNX/IP - da guida DIN KXIPI. Manuale Tecnico

Interfaccia KNX/IP - da guida DIN KXIPI. Manuale Tecnico Interfaccia KNX/IP - da guida DIN KXIPI Manuale Tecnico 24809270/15-04-2014 1 Sommario 1 Introduzione... 3 2 Applicazione... 3 3 Menù Impostazioni generali... 4 3.1 Parametri... 4 3.1.1 Nome apparecchio...

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

Reti e Internet: introduzione

Reti e Internet: introduzione Facoltà di Medicina - Corso di Laurea in Logopedia Corso di Informatica III anno Prof. Crescenzio Gallo Reti e Internet: introduzione c.gallo@unifg.it Reti e Internet: argomenti Tipologie di reti Rete

Dettagli

Istruzioni. Il cuore del dispositivo è un Embedded PC Linux che raccoglie e gestisce tutte le funzioni dell' apparecchiatura.

Istruzioni. Il cuore del dispositivo è un Embedded PC Linux che raccoglie e gestisce tutte le funzioni dell' apparecchiatura. Istruzioni D-Cold Room Datalogger è un dispositivo nato con lo scopo di monitorare le celle refrigerate, gli armadi frigo e qualunque altro apparecchio che necessiti di un controllo costante e continuo.

Dettagli

Guida all uso. Esso sarà riportato nell intestazione. Vediamo:

Guida all uso. Esso sarà riportato nell intestazione. Vediamo: faxm@il è un applicazione che permette agli utenti dei sistemi di telefonia IP di inviare, ricevere e gestire fax. Il tradizionale sistema di fax è ormai superato. Con faxm@il non riceviamo né spediamo

Dettagli

ALBO PRETORIO WEB MANUALE DELLA PROCEDURA SOMMARIO. Uso del manuale. Informazioni generali. Interfaccia grafica. Guida di riferimento

ALBO PRETORIO WEB MANUALE DELLA PROCEDURA SOMMARIO. Uso del manuale. Informazioni generali. Interfaccia grafica. Guida di riferimento #K$+ SOMMARIO ALBO PRETORIO WEB SOMMARIO Uso del manuale Informazioni generali Interfaccia grafica Guida di riferimento Guida alle operazioni ricorrenti Appendici # 000 K SOMMARIO $ SOMMARIO + 00001 Pagina

Dettagli

EW1051 Lettore di schede USB

EW1051 Lettore di schede USB EW1051 Lettore di schede USB 2 ITALIANO EW1051 Lettore di schede USB Contenuti 1.0 Introduzione... 2 1.1 Funzioni e caratteristiche... 2 1.2 Contenuto della confezione... 2 2.0 Installazione del EW1051

Dettagli

La VPN con il FRITZ!Box Parte II. La VPN con il FRITZ!Box Parte II

La VPN con il FRITZ!Box Parte II. La VPN con il FRITZ!Box Parte II La VPN con il FRITZ!Box Parte II 1 Introduzione In questa mini-guida mostreremo com è possibile creare un collegamento su Internet tramite VPN(Virtual Private Network) tra il FRITZ!Box di casa o dell ufficio

Dettagli

BDX 3D-EDITOR (autore: Marco Bedulli) Scopo del software. Caratteristiche fondamentali. Linguaggi utilizzati. Navigazione 3D

BDX 3D-EDITOR (autore: Marco Bedulli) Scopo del software. Caratteristiche fondamentali. Linguaggi utilizzati. Navigazione 3D BDX 3D-EDITOR (autore: Marco Bedulli) Scopo del software BDX 3D Editor è un programma che permette di navigare ed editare texture in un qualsiasi modello 3D.E compatibile con i software in grado di esportare

Dettagli

maggio 2013 Elevend srl Pag. 1/25

maggio 2013 Elevend srl Pag. 1/25 maggio 2013 Elevend srl Pag. 1/25 Che cos è V-Lite? V-Lite è un sistema di telemetria che permette di raccogliere i dati EVADTS dai Distributori Automatici in due modalità: Real Time: con gateway GPRS

Dettagli

I MODULI Q.A.T. PANORAMICA. La soluzione modulare di gestione del Sistema Qualità Aziendale

I MODULI Q.A.T. PANORAMICA. La soluzione modulare di gestione del Sistema Qualità Aziendale La soluzione modulare di gestione del Sistema Qualità Aziendale I MODULI Q.A.T. - Gestione clienti / fornitori - Gestione strumenti di misura - Gestione verifiche ispettive - Gestione documentazione del

Dettagli

INDIRIZZI IP AUTORIZZATI

INDIRIZZI IP AUTORIZZATI INDIRIZZI IP AUTORIZZATI Brand Item Legrand 573992, 03565 MH200, MH200N BTicino F453, F453AV, F452, F452V www.myopen-legrandgroup.com 1 Document History Version Date Author 1.0.0 01/10/2010 My Open Staff

Dettagli

Sistema Informativo di Teleraccolta EMITTENTI

Sistema Informativo di Teleraccolta EMITTENTI Sistema Informativo di EMITTENTI aventi l Italia come Stato membro di origine i cui valori mobiliari sono ammessi alla negoziazione in un altro Stato membro dell Unione Europea Art. 116 bis, comma 1, del

Dettagli

Architettura del. Sintesi dei livelli di rete. Livelli di trasporto e inferiori (Livelli 1-4)

Architettura del. Sintesi dei livelli di rete. Livelli di trasporto e inferiori (Livelli 1-4) Architettura del WWW World Wide Web Sintesi dei livelli di rete Livelli di trasporto e inferiori (Livelli 1-4) - Connessione fisica - Trasmissione dei pacchetti ( IP ) - Affidabilità della comunicazione

Dettagli

Software Servizi Web UOGA

Software Servizi Web UOGA Manuale Operativo Utente Software Servizi Web UOGA S.p.A. Informatica e Servizi Interbancari Sammarinesi Strada Caiese, 3 47891 Dogana Tel. 0549 979611 Fax 0549 979699 e-mail: info@isis.sm Identificatore

Dettagli

2.0 Gli archivi. 2.1 Inserire gli archivi. 2.2 Archivio Clienti, Fornitori, Materiali, Noleggi ed Altri Costi. Impresa Edile Guida all uso

2.0 Gli archivi. 2.1 Inserire gli archivi. 2.2 Archivio Clienti, Fornitori, Materiali, Noleggi ed Altri Costi. Impresa Edile Guida all uso 2.0 Gli archivi All interno della sezione archivi sono inserite le anagrafiche. In pratica si stratta di tutti quei dati che ricorreranno costantemente all interno dei documenti. 2.1 Inserire gli archivi

Dettagli

FRANCESCO MARINO - TELECOMUNICAZIONI

FRANCESCO MARINO - TELECOMUNICAZIONI Classe: Data Autore: Francesco Marino http://www.francescomarino.net info@francescomarino.net Esercitazione n. 18 Creazione e configurazione di una connessione remota in Windows 9x Gruppo: Alunni assenti

Dettagli

Servizio Monitoraggio Energia via Web. CEAM CWS32-H01 Professional Web Platform

Servizio Monitoraggio Energia via Web. CEAM CWS32-H01 Professional Web Platform Servizio Monitoraggio Energia via Web CEAM CWS32-H01 Professional Web Platform Cosa è CWS32-H01 Piattaforma Tecnologica Web Modulare Multifunzionale per il Monitoraggio, Telecontrollo Gestione Manutenzione,

Dettagli

WorkFLow (Gestione del flusso pratiche)

WorkFLow (Gestione del flusso pratiche) WorkFLow (Gestione del flusso pratiche) Il workflow è l'automazione di una parte o dell'intero processo aziendale dove documenti, informazioni e compiti vengono passati da un partecipante ad un altro al

Dettagli

RICEZIONE AUTOMATICA DEI CERTIFICATI DI MALATTIA 1.1. MALATTIE GESTIONE IMPORT AUTOMATICO 1.2. ATTIVAZIONE DELLA RICEZIONE DEL FILE CON L INPS

RICEZIONE AUTOMATICA DEI CERTIFICATI DI MALATTIA 1.1. MALATTIE GESTIONE IMPORT AUTOMATICO 1.2. ATTIVAZIONE DELLA RICEZIONE DEL FILE CON L INPS RICEZIONE AUTOMATICA DEI CERTIFICATI DI MALATTIA 1.1. MALATTIE GESTIONE IMPORT AUTOMATICO Abbiamo predisposto il programma di studio Web per la ricezione automatica dei certificati di malattia direttamente

Dettagli

A intervalli regolari ogni router manda la sua tabella a tutti i vicini, e riceve quelle dei vicini.

A intervalli regolari ogni router manda la sua tabella a tutti i vicini, e riceve quelle dei vicini. Algoritmi di routing dinamici (pag.89) UdA2_L5 Nelle moderne reti si usano algoritmi dinamici, che si adattano automaticamente ai cambiamenti della rete. Questi algoritmi non sono eseguiti solo all'avvio

Dettagli

ELENCO CLIENTI FORNITORI Patch1

ELENCO CLIENTI FORNITORI Patch1 ELENCO CLIENTI FORNITORI Patch1 Il pacchetto P15_200ElencoCF_Patch1.exe contiene una serie di aggiornamenti alla procedura di generazione del file contenente l. Download: 1) Assicurarsi di avere una versione

Dettagli

Guida all Utilizzo dell Applicazione Centralino

Guida all Utilizzo dell Applicazione Centralino Guida all Utilizzo dell Applicazione Centralino 1 Introduzione Indice Accesso all applicazione 3 Installazione di Vodafone Applicazione Centralino 3 Utilizzo dell Applicazione Centralino con accessi ad

Dettagli

Alfa Layer S.r.l. Via Caboto, 53 10129 Torino ALFA PORTAL

Alfa Layer S.r.l. Via Caboto, 53 10129 Torino ALFA PORTAL ALFA PORTAL La struttura e le potenzialità della piattaforma Alfa Portal permette di creare, gestire e personalizzare un Portale di informazione in modo completamente automatizzato e user friendly. Tramite

Dettagli

IT Cloud Service. Semplice - accessibile - sicuro - economico

IT Cloud Service. Semplice - accessibile - sicuro - economico IT Cloud Service Semplice - accessibile - sicuro - economico IT Cloud Service - Cos è IT Cloud Service è una soluzione flessibile per la sincronizzazione dei file e la loro condivisione. Sia che si utilizzi

Dettagli

GUIDA DI INSTALLAZIONE E PRIMA CONFIGURAZIONE DI EDILCONNECT PER I CONSULENTI

GUIDA DI INSTALLAZIONE E PRIMA CONFIGURAZIONE DI EDILCONNECT PER I CONSULENTI 1 GUIDA DI INSTALLAZIONE E PRIMA CONFIGURAZIONE DI EDILCONNECT PER I CONSULENTI Introduzione Dal 24 ottobre è possibile per i consulenti effettuare l installazione e la configurazione del nuovo applicativo

Dettagli

Configurazione di Outlook Express

Configurazione di Outlook Express OUTLOOK Outlook Express è il client di posta elettronica sviluppato da Microsoft, preinstallato su sistemi operativi Windows a partire da Windows 98 fino all'uscita di Windows XP. Con l'arrivo di Windows

Dettagli

Manuale Utente Albo Pretorio GA

Manuale Utente Albo Pretorio GA Manuale Utente Albo Pretorio GA IDENTIFICATIVO DOCUMENTO MU_ALBOPRETORIO-GA_1.4 Versione 1.4 Data edizione 04.04.2013 1 TABELLA DELLE VERSIONI Versione Data Paragrafo Descrizione delle modifiche apportate

Dettagli

Manuale di Aggiornamento BOLLETTINO. Rel. 5.20.1H4. DATALOG Soluzioni Integrate a 32 Bit

Manuale di Aggiornamento BOLLETTINO. Rel. 5.20.1H4. DATALOG Soluzioni Integrate a 32 Bit Manuale di Aggiornamento BOLLETTINO Rel. 5.20.1H4 DATALOG Soluzioni Integrate a 32 Bit - 2 - Manuale di Aggiornamento Sommario 1 2 PER APPLICARE L AGGIORNAMENTO... 3 1.1 Aggiornamento Patch Storica...

Dettagli

GUIDA UTENTE MONEY TRANSFER MANAGER

GUIDA UTENTE MONEY TRANSFER MANAGER GUIDA UTENTE MONEY TRANSFER MANAGER (vers. 1.0.2) GUIDA UTENTE MONEY TRANSFER MANAGER (vers. 1.0.2)... 1 Installazione... 2 Prima esecuzione... 5 Login... 7 Funzionalità... 8 Anagrafica... 9 Registrazione

Dettagli

3. Introduzione all'internetworking

3. Introduzione all'internetworking 3. Introduzione all'internetworking Abbiamo visto i dettagli di due reti di comunicazione: ma ce ne sono decine di tipo diverso! Occorre poter far comunicare calcolatori che si trovano su reti di tecnologia

Dettagli

Firewall, Proxy e VPN. L' accesso sicuro da e verso Internet

Firewall, Proxy e VPN. L' accesso sicuro da e verso Internet L' accesso sicuro da e verso Internet L' accesso ad Internet è ormai una necessità quotidiana per la maggior parte delle imprese. Per garantire la miglior sicurezza mettiamo in opera Firewall sul traffico

Dettagli

FPf per Windows 3.1. Guida all uso

FPf per Windows 3.1. Guida all uso FPf per Windows 3.1 Guida all uso 3 Configurazione di una rete locale Versione 1.0 del 18/05/2004 Guida 03 ver 02.doc Pagina 1 Scenario di riferimento In figura è mostrata una possibile soluzione di rete

Dettagli

Gui Gu d i a d ra r p a i p d i a V d o a d f a one Int fone In e t r e net rnet Box Key Mini

Gui Gu d i a d ra r p a i p d i a V d o a d f a one Int fone In e t r e net rnet Box Key Mini Guida rapida Vodafone Internet Key Box Mini Ideato per Vodafone QSG_VMCLite_v31_10-2007_e172_IT.1 1 10/10/07 14:39:10 QSG_VMCLite_v31_10-2007_e172_IT.2 2 10/10/07 14:39:11 Benvenuti nel mondo della connessione

Dettagli

Guida rapida Vodafone Internet Box

Guida rapida Vodafone Internet Box Guida rapida Vodafone Internet Box Benvenuti nel mondo della connessione dati in mobilità di Vodafone Internet Box. In questa guida spieghiamo come installare e cominciare a utilizzare Vodafone Internet

Dettagli

Ubiquity getting started

Ubiquity getting started Introduzione Il documento descrive I passi fondamentali per il setup completo di una installazione Ubiquity Installazione dei componenti Creazione del dominio Associazione dei dispositivi al dominio Versione

Dettagli

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 2005, ore 15.00

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 2005, ore 15.00 Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 200, ore 1.00 NB: alcune domande hanno risposta multipla: si richiede di identificare TUTTE le risposte corrette. Cognome: Nome:

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

SDD System design document

SDD System design document UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) http://www.magsoft.it/progettodocs

Dettagli

L insieme di queste funzioni, costituisce un sistema completo di gestione e controllo del lavoro di ogni Punto Vendita.

L insieme di queste funzioni, costituisce un sistema completo di gestione e controllo del lavoro di ogni Punto Vendita. 35. Orari di Lavoro Le Aziende di medie o grandi dimensioni hanno spesso la necessità di tenere monitorati gli orari di attività dei propri Punti Vendita e del personale. Shop_Net offre una serie di funzioni

Dettagli

Capitolo 4 Pianificazione e Sviluppo di Web Part

Capitolo 4 Pianificazione e Sviluppo di Web Part Capitolo 4 Pianificazione e Sviluppo di Web Part Questo capitolo mostra come usare Microsoft Office XP Developer per personalizzare Microsoft SharePoint Portal Server 2001. Spiega come creare, aggiungere,

Dettagli

Attività federale di marketing

Attività federale di marketing Attività federale di marketing Gestione e certificazione delle sponsorizzazioni Il Feedback Web Nel piano di sviluppo della propria attività di marketing, la FIS ha adottato il sistema Feedback Web realizzato

Dettagli

Dott. Davide Tamellini Ing. Vittorio Agostinelli. Automazione. AssoAutomazione

Dott. Davide Tamellini Ing. Vittorio Agostinelli. Automazione. AssoAutomazione La gestione dell IP dinamico in rete GPRS con utilizzo del protocollo IEC60870: il concetto di Plc Gprs Manager, nella comunicazione wireless con standard IEC, applicato alle reti idriche geograficamente

Dettagli

SmartGPS Satellite Information System Guida all utilizzo del programma Sviluppato da Fabio e Marco Adriani Versione 1.0.0

SmartGPS Satellite Information System Guida all utilizzo del programma Sviluppato da Fabio e Marco Adriani Versione 1.0.0 SmartGPS Satellite Information System Guida all utilizzo del programma Sviluppato da Fabio e Marco Adriani Versione 1.0.0 Benvenuto in SmartGPS, l'applicativo che consente di determinare, utilizzando un

Dettagli

http://www.ilveliero.info veliero@samnet.it Il nuovo browser italiano dedicato alla navigazione e comunicazione sicura in internet per bambini

http://www.ilveliero.info veliero@samnet.it Il nuovo browser italiano dedicato alla navigazione e comunicazione sicura in internet per bambini http://www.ilveliero.info veliero@samnet.it Il nuovo browser italiano dedicato alla navigazione e comunicazione sicura in internet per bambini versione scuola SAM Via di Castro Pretorio, 30 00185 ROMA

Dettagli

Come funziona il WWW. Architettura client-server. Web: client-server. Il protocollo

Come funziona il WWW. Architettura client-server. Web: client-server. Il protocollo Come funziona il WWW Il funzionamento del World Wide Web non differisce molto da quello delle altre applicazioni Internet Anche in questo caso il sistema si basa su una interazione tra un computer client

Dettagli

RETI DI COMPUTER Reti Geografiche. (Sez. 9.8)

RETI DI COMPUTER Reti Geografiche. (Sez. 9.8) RETI DI COMPUTER Reti Geografiche (Sez. 9.8) Riepilogo Reti lez precedente reti locali o LAN (Local Area Network): connette fisicamente apparecchiature su brevi distanze Una LAN è solitamente interna a

Dettagli

COME CREARE UNA COMUNICAZIONE / NEWSLETTER

COME CREARE UNA COMUNICAZIONE / NEWSLETTER COME CREARE UNA COMUNICAZIONE / NEWSLETTER Benvenuti nella MINI GUIDA di Centrico per la creazione di una nuova Comunicazione o Newsletter. Grazie a questa guida, potrai creare delle comunicazioni ad hoc

Dettagli

WEB SEMINAR Dettaglio servizio

WEB SEMINAR Dettaglio servizio WEB SEMINAR Dettaglio servizio INTRODUZIONE L organizzazione di un web seminar prevede diverse e ben distinte fasi che iniziano con la promozione dell evento e si concludono con i report relativi alle

Dettagli

Generazione Automatica di Asserzioni da Modelli di Specifica

Generazione Automatica di Asserzioni da Modelli di Specifica UNIVERSITÀ DEGLI STUDI DI MILANO BICOCCA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea Magistrale in Informatica Generazione Automatica di Asserzioni da Modelli di Specifica Relatore:

Dettagli

Per cosa posso utilizzarlo?

Per cosa posso utilizzarlo? Guida rapida Vodafone Mobile Connect Card Express Vodafone Broadband Benvenuti nel mondo della connessione dati in mobilità di Vodafone Mobile Connect Card Express. In questa guida spieghiamo come installare

Dettagli

itime Chiaramente inclusa la stampa del cartellino presenze come previsto dalle normative

itime Chiaramente inclusa la stampa del cartellino presenze come previsto dalle normative itime itime Il software di rilevazione presenze itime rappresenta lo strumento ideale per l automatizzazione della gestione del personale. L ampia presenza dei parametri facilita l operatore nel controllo

Dettagli

Verifica scritta di Sistemi e Reti Classe 5Di 26.11.2015

Verifica scritta di Sistemi e Reti Classe 5Di 26.11.2015 Verifica scritta di Sistemi e Reti Classe 5Di 26.11.2015 Una azienda specializzata nella fornitura di servizi Internet quali hosting, housing, email, file server, in pratica un ISP (Internet Service Provider)

Dettagli

Capire i benefici di una rete informatica nella propria attività. I componenti di una rete. I dispositivi utilizzati.

Capire i benefici di una rete informatica nella propria attività. I componenti di una rete. I dispositivi utilizzati. LA RETE INFORMATICA NELL AZIENDA Capire i benefici di una rete informatica nella propria attività. I componenti di una rete I dispositivi utilizzati I servizi offerti LA RETE INFORMATICA NELL AZIENDA Copyright

Dettagli