Indice. Introduzione 1

Transcript

1 Indice Introduzione 1 1 Applicazioni dependable per il mobile computing di nuova generazione 5 11 I nuovi scenari applicativi per il mobile computing 5 12 Il concetto di dependability per applicazioni mobili 7 13 Tecnologie wireless a supporto del mobile computing La tecnologia Bluetooth: concetti generali 14 2 Dependability e metodologie di failure data analysis Il concetto di dependability nel tempo Sistema, servizio, interfaccia Gli attributi di dependability Dependability measures Dependability threats Faults Errors Failures Propagazione delle minacce: la catena fault, error, failure Dependability means Fault avoidance Fault tolerance Tecniche di fault tolerance Stati di un sistema fault tolerant Fault removal Fault forecasting La failure data analysis Field failure data analysis Un caso di studio: Windows NT 48 ii

2 INDICE iii 3 Failure Data Analysis di reti Bluetooth Obiettivi e metodologie La generazione e la raccolta dei dati Architettura per la raccolta dati Emulazione del traffico: BlueTest ed i profili di carico Filtraggio e coalescenza dei dati: il LogAnalyzer Stato dell arte 73 4 La dependability del profilo PAN Il profilo PAN Il testbed Linux e Bluetooth: lo stack BlueZ BlueZ e il profilo PAN Windows XP e Bluetooth Lo stack Broadcom BlueTest e il profilo PAN La gestione degli errori e le azioni di recovery BlueTestPAN in ambiente Linux Progettazione ed implementazione del client BlueTestPAN per Windows XP Gestione delle connessioni: il package BTWConnMng Gestione delle eccezioni Da Linux a Windows Dettagli tecnici ed ambiente di sviluppo Risultati sperimentali I fallimenti Azioni di recovery Fallimenti e Workload Le sessioni La distribuzione dei fallimenti nel tempo Scan ed sdp search Progettazione di un testbed RFCOMM Il livello RFCOMM Il testbed Progettazione del software BlueTestRfcomm Protocollo di orchestrazione dei peer Versione Base Versione Adattativa Emulazione del traffico: i profili di carico Le interfacce BlueTestRfcomm in ambiente Windows XP Classi per la comunicazione Bluetooth su RFCOMM Classe per la gestione dei timer 137

3 INDICE iv 543 Classe per la gestione delle eccezioni Implementazione del protocollo di orchestrazione Implementazione della versione base Implementazione della versione adattativa Valutazione sperimentale del protocollo di orchestrazione in ambiente Win XP Versione Base Versione Adattativa 146 Conclusioni 151 A How to 155 A1 BlueZ 155 A11 Installazione ed inizializzazione dello stack 155 A12 Comandi per la gestione di una sessione Bluetooth 156 A13 Creazione di una connessione PAN 156 A2 Sviluppo di applicazioni per Windows XP 158 A21 MicrosoftNet 158 A22 Sviluppo di applicazioni Bluetooth 159 A221 Esempio di una tipica applicazione Bluetooth 159 A23 Reboot e Shutdown di una macchina Windows 162 A3 Broadcomm: lo stack BCM1000-BTW 164 A31 Ambiente di sviluppo ed istruzioni di compilazione 164 A32 Descrizione delle API 169 A321 Esempio di una tipica applicazione Bluetooth 169 A322 Problemi di sincronizzazione: il meccanismo degli eventi di Windows 172 B Bluetooth 175 B1 Introduzione 175 B2 Lo stack Bluetooth 175 B203 Livello radio 175 B204 Livello Baseband 177 B205 Livello Link Manager 185 B206 Livello L2CAP 185 B207 RFCOMM 188 B208 SDP 190 Bibliografia 193

4 Elenco delle figure 11 Scenario di utilizzo tipico di un applicazione mobile 9 12 Previsione dell andamento della domanda di mobile devices Alternanza nell accesso al canale tra il master ed uno slave Bluetooth scatternet Bluetooth Stack Bluetooth Profiles Organization Andamento del failure rate di un componente Binary state model Attributi di dependability MTTF,MTBF,MTTR Tassonomia dei faults (Laprie, 2004) Tassonomia dei fallimenti (Laprie, 2004) Patologia dei guasti Propagazione esterna dei guasti Strategie di tolleranza ai guasti (Laprie, 2004) Diagramma degli stati di un sistema fault tolerant Strategie di verifica (Laprie, 2004) Fault Removal During Development Fasi della field failure data anlysis (Iyer, 2000) Esempio di log entry Modello a stati finiti di un singolo host (Iyer, 2000) Modello a stati finiti del dominio (Iyer, 2000) Distribuzione dei tempi di inter-reboot Studio della dependability di Bluetooth Diagramma di alto livello del sistema di raccolta dati Vettore dei parametri caratteristici di una sessione Diagramma di alto livello del LogAnalyzer BNEP: Incapsulamento di un frame Ethernet in un pacchetto L2CAP Dettaglio dello stack Bluetooth PAN:scenario di utilizzo NAP 78 v

5 ELENCO DELLE FIGURE vi 44 PAN: Scenario Group Ad Hoc Networking Architettura del testbed Microsoft Bluetooth Stack Diagramma a blocchi del BTW Development Kit Classi offerte dal BCM1000-BTW DK BlueTest: flusso di esecuzione in assenza di errori Diagramma degli stati dettagliato di BlueTestPAN BlueTest: flusso di esecuzione in presenza di errori Diagramma delle classi Connection e BlueConnection Gerarchia di classi Workload Diagramma delle classi per la gestione delle connessioni BTWConnection: eccezioni PAN: eccezioni L2CAP: eccezioni Percentuale dei diversi tipi di fallimento Tipi di fallimento sull intero testbed, visione 3D Tipi di fallimento sull intero testbed, schema Azioni di recovery Azioni di recovery relative ai singoli fallimenti Percentuale dei fallimenti in relazione al profilo in esecuzione Percentuale dei fallimenti in relazione all attività corrente Frequenza dei fallimenti in relazione alla durata della sessione e all attività corrente Frequenza dei fallimenti nell arco di una sessione Frequenza dei fallimenti in relazione al numero di pacchetti in una sessione LowLevelTest Andamento della percentuale dei fallimenti nell arco di una sessione P2P Frequenza di fallimento in corrispondenza di scan e/o sdp search, visione 3D Percentuale dei fallimenti in corrispondenza di scan e/o sdp search, schema Profili basati su RFCOMM Architettura del testbed Diagramma degli stati di alto livello di un nodo Bluetooth Orchestrazione dei peer Azione di controllo per il bilanciamento dei tempi Azione di controllo per la gestione delle connessioni RfcommConnectionInterfaces TimeManagerInterface RandomGeneratorInterface ProfilesInterface ExceptionInterface 135

6 ELENCO DELLE FIGURE vii 512 Classi per la comunicazione Bluetooth su RFCOMM Classe per la gestione dei timer Classe per la gestione delle eccezioni BlueLog Diagrammi delle classi Valore del rapporto Ts/Tc Parametri di connessione Schema riassuntivo della sessione di test Andamento del rapporto R Numero di connessioni, schema Numero di connessioni 150 A1 Stream Server 161 A2 Snapshot di Visual C A3 Creazione di un progetto vuoto 165 A4 Eliminazione delle classi MFC 166 A5 Impostazione dei path predefiniti 166 A6 Direttive al preprocessore 167 A7 Inclusione dei file lib 168 A8 Impostazione delle librerie a run time 168 B1 Bluetooth Stack 176 B2 Topologie di una rete Bluetooth 178 B3 Assegnazione degli slots in una piconet 178 B4 Tipi di pacchetto Bluetooth 180 B5 Assegnazione degli slots in una piconet 182 B6 Diagramma degli stati Bluetooth 183 B7 Possibili stati di un dispositivo appartenente ad una piconet 184 B8 Collegamento a livello L2CAP 186 B9 Principali livelli basati su L2CAP 187 B10 Livello HCI 188 B11 Connessione Rfcomm 190 B12 Strutture dati del protocollo SDP 191

7 Elenco delle tabelle 11 Tecnologie Wireless Dependability Measures Parametri del test Breakup dei reboot in base ai prominent events (Iyer, 2000) Statistiche sui tempi di up e down Statistiche sulle percentuali di Availability Interpretazione degli stati del modello del dominio (Iyer, 2000) Percentuali di utilizzo dei protocolli in Internet Testbed, caratteristiche tecniche Probabilità di occorrenza per SCAN ed SDP SEARCH Azioni di recovery Funzioni per l implementazione delle azioni di recovery Caratteristiche della sessione di test Schema riassuntivo delle modalità di fallimento Classificazione delle sessioni in base alla durata 114 A1 File per l installazione di BlueZ 155 A2 Comandi hcitool 157 A3 Classi per la gestione di livelli e profili 169 B1 Caratteristiche del livello Radio 177 B2 Tipi di Pacchetto ACL 183 B3 Tipi di frames RFCOMM 189 viii

8 Mon titre Moi-même mars 2001

9 Introduzione Il mercato dei dispositivi mobili di ultima generazione ha subito una decisa impennata grazie ai continui progressi nel campo della wireless communication e della produzione di hardware dedicato Dispositivi sempre più evoluti in termini di capacità di elaborazione, memoria e connettività hanno invaso gli ambienti professionali e di intrattenimento rendendo il mobile computing uno tra i paradigmi di comunicazione ad oggi più utilizzato L enorme diffusione di tecnologie mobili avanzate ha aperto la strada ad una vasta gamma di contesti applicativi spesso altamente critici sia in termini economici (business-critical scenarios) sia in termini di affidabilità e sicurezza (mission-critical scenarios): il telecontrollo, la telemedicina, la domotica ed il mobile-learning per citarne alcuni Sviluppare applicazioni mobili per realizzare simili scenari si traduce nella necessità di sviluppare applicazioni dependable, in grado cioè di soddisfarne i requisiti di qualità, promuovendo una rinnovata attenzione allo studio e all analisi dell affidabilità delle tecnologie wireless a supporto del mobile computing Per i costi contenuti, la semplicità di utilizzo e la larga diffusione sul mercato, la tecnologia Bluetooth sembra destinata a dominare gli scenari mobile del prossimo futuro Dal momento che ancora poco si conosce del suo comportamento in termini di affidabilità, il presente lavoro di tesi si propone quale obiettivo lo studio sperimentale della sua dependability valutata in funzione della piattaforma hardware utilizzata, del software e del profilo ap- 1

10 2 plicativo In particolare, data l elevata percentuale di utilizzo di Bluetooth quale tecnologia per il last meter access e per il trasferimento di contenuti multimediali tra dispositivi Bluetooth enabled, si è scelto di considerare i profili legati al paradigma del Personal Area Networking (PAN) ed i profili basati sul protocollo di trasporto seriale (RFCOMM) Inoltre, si è scelto di installare i sistemi operativi di più largo consumo su piattaforme hardware sia fisse sia mobili L approccio utilizzato per la valutazione della dependability è basato sulla misurazione diretta e dunque su tecniche di field-failure data analysis per le quali la raccolta e l analisi dei dati relativi ai fallimenti del sistema in esercizio costituiscono la base per valutazioni generali sull affidabilità L esigenza di una quantità di dati tale da conferire rilevanza statistica all analisi ha indotto alla realizzazione di software applicativo per la generazione di traffico emulato e per la raccolta di dati provenienti da sorgenti di traffico reale Inoltre, il bisogno di automatizzare le procedure di raccolta, manipolazione e classificazione dei dati ha reso necessaria la realizzazione di un articolata infrastruttura software, distribuita su più nodi di elaborazione Obiettivo fondamentale della campagna di raccolta e di analisi dei dati condotta nel presente lavoro è l individuazione delle modalità di fallimento delle reti Bluetooth e la loro caratterizzazione statistica Il conseguimento di tale obiettivo costituisce una importante base di conoscenza utile per la valutazione del grado di dependability, per l applicazione di tecniche di dependability improvement e, infine, per l individuazione dei failure pattern più comuni, in grado di suggerire strategie di programmazione per lo sviluppo di applicazioni dependable Il lavoro si articola in cinque capitoli di cui nel seguito si fornisce una breve descrizione

11 3 Il Capitolo 1 introduce al mobile computing di nuova generazione attraverso la descrizione dei numerosi scenari applicativi ponendo l accento sui loro aspetti critici, sul concetto di qualità e sull interpretazione del concetto di dependability per applicazioni mobili Inoltre, a valle di una breve introduzione alle tecnologie wireless di supporto alla comunicazione e di considerazioni sulla loro diffusione, vengono forniti i concetti generali della tecnologia Bluetooth Il Capitolo 2 costituisce uno studio monografico sulla dependability ed i concetti ad essa correlati Dopo una breve ricostruzione dell idea di dependability nel tempo, vengono descritti gli attributi ed i parametri quantitativi per la stima del grado di affidabilità di un sistema; viene poi fornita una descrizione delle minacce alla dependability di un sistema e delle strategie, dependability means, per la prevenzione, la tolleranza ed il recupero di situazioni di errore L ultima parte descrive le metodologie di analisi di dati relativi ai fallimenti con particolare attenzione alla field-failure data analysis, cui è dedicato il caso di studio che chiude il capitolo Nel Capitolo 3 si illustrano gli obiettivi dello studio della dependability di Bluetooth e le metodologie proposte dal presente lavoro di tesi All interpretazione generale dell affidabilità di Bluetooth quale funzione di tre parametri, segue l illustrazione dell approccio measurement-based che si è scelto di adottare La parte centrale è dedicata alla descrizione delle modalità di generazione dei dati e alla presentazione dell architettura software utilizzata per la raccolta Segue la descrizione del software per l emulazione del traffico su reti Bluetooth, BlueTest, e la modellazione statistica dei workload Per l analisi dei dati raccolti è stata necessaria l applicazione degli algoritmi di filtraggio e coalescenza descritti in dettaglio nella parte finale del capitolo Il Capitolo 4 è interamente dedicato allo studio della dependability di Bluetooth relativamente al profilo PAN Ad una breve illustrazione del profilo segue la descrizione dettagliata del testbed e dei supporti Bluetooth offerti dai sistemi operativi Windows e Linux Per la generazione del traffico

12 4 e l esecuzione di azioni di ripristino è stata implementata una versione di BlueTest, BlueTestPAN, di cui viene dettagliatamente descritto il comportamento Con riferimento al sistema operativo Linux si riportano cenni all implementazione del testbed; la progettazione e l implementazione di un client in ambiente Windows occupa la parte centrale del capitolo L ultima parte è dedicata ai risultati dell analisi che hanno condotto ad interessanti considerazioni circa le modalità di fallimento e l efficacia delle azioni di ripristino Nel Capitolo 5 è dedicato alla progettazione di un testbed per la valutazione della dependability di RFCOMM Per la generazione del traffico emulato su canale seriale è stata progettata una versione di BlueTest per RFCOMM, BlueTestRfcomm, di cui sono illustrate le fasi di progettazione e di implementazione in ambiente Windows Particolare attenzione è dedicata alla progettazione di un protocollo per l orchestrazione dei nodi della rete: il capitolo si chiude con la sua valutazione sperimentale, volte a stimarne il grado di sensibilità agli errori

13 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione Il mercato dei dispositivi mobili di ultima generazione ha subito una decisa impennata grazie ai continui progressi nel campo della wireless communication e della produzione di hardware dedicato La disponibilità di dispositivi sempre più potenti in termini di capacità di elaborazione, memoria e connettività ha radicalmente modificato le abitudini e le esigenze di una platea di mobile users che, allargandosi a macchia d olio, ha ormai reso il mobile computing la realtà dominante nel mondo della comunicazione sia professionale sia di intrattenimento Il presente capitolo illustra i principali scenari del paradigma mobile ponendo l accento sui loro aspetti critici, sul concetto di qualità e sul ruolo delle infrastrutture wireless di supporto alla comunicazione Per i costi contenuti, la sua semplicità e larga diffusione sul mercato, Bluetooth sembra essere la tecnologia wireless destinata a dominare il mobile computing del prossimo futuro: se ne propone un interpretazione dell affidabilità in un ottica orientata allo sviluppo di applicazioni mobili di qualità 11 I nuovi scenari applicativi per il mobile computing Figlia degli inarrestabili progressi compiuti nell ultimo decennio nel campo della wireless communication e della microelettronica, la significativa diffusione di dispositivi mobili di ultima generazione -ovvero di dispositivi dalle elevate capacità computazionali e di memorizzazione oltre che di dimensioni sempre più ridotte- suscita, tanto nel mondo accademico quanto nel 5

14 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione 6 panorama industriale mondiale, un sensibile e crescente interesse per quelle tematiche che la più recente letteratura tecnico-scientifica definisce di mobile computing Con un grosso sforzo di generalizzazione Jing at al in [JJ99] forniscono una prima interpretazione del concetto in termini di computing paradigm capace di consentire a dispositivi mobili di avere accesso a dati, informazioni e servizi pur essendo in continuo movimento In un ottica tesa invece a sottolineare il ruolo della tecnologia di comunicazione utilizzata e della tipologia di dispositivi adoperata, il concetto di mobile computing assume diverse sfumature particolarizzandosi in paradigmi specifici quali, tra gli altri, pervasive, nomadic, ad hoc computing Gli sforzi della ricerca nel tentativo di fornire soluzioni efficienti alle problematiche intrinsecamente connesse sia alla natura mobile dei dispositivi in gioco e sia ai limiti delle infrastrutture di comunicazione wireless, trovano giustificazione nella necessità di tener testa all incessante proliferare di proposte di scenari applicativi sempre nuovi e più complessi, come testimonia una ricca e fiorente bibliografia Lampe et al in [EF04] presentano una soluzione basata su tecniche di pervasive computing per la manutenzione di velivoli (aircraft manteinance); in [DS98] è presentato un progetto per la diagnosi dei guasti e la manutenzione di treni Soluzioni basate sull utilizzo di sistemi mobili sono state proposte anche per il mobile learning [PL], nel campo della domotica per il controllo a distanza di impianti di riscaldamento, illuminazione ed elettrodomestici [RJ04], ed ancora nel campo della robotica per il controllo remoto di robot [TK01] Sono poi da menzionare le numerose applicazioni del mobile computing a sistemi di telemedicina ed healthcare: Butler et al in [MB03] suggeriscono l utilizzo di dispositivi mobili a supporto del lavoro di logopedisti e personale paramedico in caso di prehospital incident, AAAziz et al in [Bes03] propongono l utilizzo di telefoni

15 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione 7 cellulari per la trasmissione di immagini biomediche, in [Bar04] Bardram pone l accento sulla context awareness in ambienti ospedalieri ( Context-Aware Hospital Bed, Context-Aware Pill Container, Context-Aware EPR ) al fine di agevolare il lavoro di consultazione dei dati clinici e lo scambio immediato di informazioni relative ai degenti oltre che le attività di monitoraggio del loro stato di salute In [HP98] si legge, infine, un originale progetto di wereable computing per il supporto ad anziani, ciechi e portatori di handicap A fare da denominatore comune per gli scenari finora menzionati, è la necessità di sviluppare applicazioni ad elevata affidabilità e dunque sistemi in grado di scongiurare, o gestire, l occorrenza di fallimenti non tollerabili [AL04]: in una sola parola, dependability 12 Il concetto di dependability per applicazioni mobili Sviluppare applicazioni mobili, o meglio sviluppare applicazioni mobili dependable, è un attività ingegneristicamente molto complessa per via sia di vincoli temporali stringenti imposti da un mercato in continua evoluzione sia delle numerose limitazioni ambientali e tecnologiche proprie del mobile environment tra cui: limitata autonomia energetica dei dispositivi; limitate risorse di banda per la wireless connectivity; necessità di operare su piattaforme eterogenee Se da un lato la richiesta di sviluppo in tempi rapidissimi sta indirizzando la ricerca verso l introduzione di nuovi modelli di sviluppo agile e quindi

16 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione 8 verso metodologie proprie dell Ingegneria del Software [PS04], la corretta gestione delle limitazioni strutturali coinvolge aspetti legati strettamente ai concetti di dependability dal momento che si fa sempre più consistente l utilizzo di sistemi mobili in scenari applicativi critici sia in termini economici (business-critical scenarios) sia in termini di affidabilità e sicurezza (mission-critical scenarios) La dependability è un macroattributo composto da una serie di attributi di qualità che assumono singolarmente una rilevanza più o meno sensibile a seconda del contesto applicativo: availability, ossia la disponibilità di un sistema in un certo istante; maintainability, ossia la possibilità di sottoporre facilmente il sistema a manutenzione e riparazione; reliability, ossia la probabilità che il sistema funzioni correttamente in un determinato istante; safety, ossia la probabilità che in un certo istante non si verifichino guasti catastrofici; performability, ossia la misura del livello di performance del sistema anche in presenza di guasti; security, ossia l insieme di proprietà che rendono in sistema non impropriamente alterabile nello stato La maggior parte delle applicazioni mobili fornisce all utente finale l accesso alla rete Internet, o più in generale a risorse remote, secondo lo schema in Figura 11 in cui il dispositivo mobile, lato client, comunica attraverso un infrastruttura wireless con una base station (AP Access Point)

17 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione 9 che garantisce la connettività con gli host della rete wired cui è connesso, ie un WWW server per la navigazione di siti web, un FTP server per il download/upload di dati o un server per il controllo remoto di un robot BASE STATION Internet PDA Figura 11: Scenario di utilizzo tipico di un applicazione mobile In situazioni del genere, è evidente che l affidabilità dell infrastruttura wireless di supporto incide in misura sensibile sull affidabilità dell applicazione nel suo complesso: un ritardo nel trasferimento di un comando ad un veicolo telecontrollato o l impossibilità di accesso ad un sito web ad esempio a causa di congestione della rete potrebbero sortire effetti devastanti arrecando rispettivamente danni a vite umane ed ingenti perdite economiche! Un discorso analogo vale per la qualità del mobile device: problemi di natura hardware o bugs nel software di sistema non sarebbero certamente meno carichi di conseguenze Sebbene la ricerca si stia adoperando nella formulazione di soluzioni atte a migliorare la dependability di alcune tra le tecnologie wireless più utilizzate, tra cui Wi-Fi (Wireless Fidelity) [DC03], e per la produzione di hardware dedicato sempre più affidabile, è realisticamente impensabile poter contare su infrastrutture di supporto che siano completamente dependable, ovvero la cui probabilità di fallimento sia nulla Ad un applicazione mobile

18 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione 10 dependable, pertanto, è richiesto non l utilizzo di hardware e reti completamente affidabili ma di infrastrutture di supporto il cui comportamento in termini di affidabilità (dependability behavior) sia predicibile in modo da poter opportunamente gestire l inevitabile occorrenza di fallimenti Lo sviluppo di applicazioni affidabili richiede pertanto una rinnovata attenzione allo studio e all analisi della dependability delle tecnologie wireless esistenti con l intento non soltanto di poterne formalizzare il comportamento e proporre strategie di prevenzione, tolleranza e recupero di situazioni di errore ma anche di: valutare la dependability di applicazioni esistenti basate su una determinata tecnologia; individuare sequenze di operazioni critiche da evitare nello sviluppo di applicazioni 13 Tecnologie wireless a supporto del mobile computing Lo sviluppo cui assiste il mercato nel giovane settore della wireless communication sembra un fenomeno senza precedenti, come dimostrano le numerose ricerche di mercato condotte sia da importanti istituti di ricerca sia dalle divisioni di marketing delle più importanti multinazionali del settore: secondo gli analisti della divisione finanziaria di Telenor, la prima compagnia di telecomunicazioni norvegese, il mercato dei mobile devices -prescindendo dalla tipologia di dispositivo e dalla tecnologia di accesso supportata- sembra destinato a crescere almeno fino al 2011 [IG05] come illustrato in Figura 12 Molto eloquenti anche le previsioni di Telecom Italia secondo cui in Europa occidentale la vendita di wireless PC card (UMTS/GPRS), crescendo del 48%/anno nel periodo , raggiungerà i 5,7 milioni mentre i

19 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione 11 Figura 12: Previsione dell andamento della domanda di mobile devices mobile worker dagli 11,7 milioni di fine 2004 passeranno ai 35 milioni di fine 2008 registrando un aumento del 31%/anno [CP05] Al contempo causa e conseguenza di un aumento tanto sensibile della domanda è il fiorire di tecnologie di comunicazione wireless caratterizzate da servizi sempre più evoluti: presumibilmente nell arco del prossimo decennio la percentuale di dispositivi GSM sarà praticamente trascurabile mentre le vendite di dispositivi di terza e quarta generazione (3G 4G devices) subiranno una decisa impennata [IG05] Al fine di disciplinare il mercato e di favorire l interoperabilità tra dispositivi differenti, l IEEE ha emanato negli anni una serie di specifiche standard relative alle singole tecnologie come è sintetizzato in Tabella 11 in cui si riporta, tra le altre cose, la tipologia di applicazioni per cui ognuna di esse è concepita (TARGET) FreqBand Range Power PhysThr EffThr Region Target Bluetooth 24 Ghz 100m VeryLow 10Mbps 6Mbps World CableRepl Home RF2 24 Ghz 50m Medium 10Mbps 6Mbps US/Asia Voice/Data 80211b 24 Ghz 150m Medium 11Mbps 7Mbps World Voice/Data 80211a 5 Ghz 50m Med/High 54Mbps 31Mbps US/Asia Voice/Data 80211g 24 Ghz 150m Med/High 22Mbps 12Mbps World Voice/Data Hiperlan2 5 Ghz 80m Medium 54Mbps 31Mbps Europe Voice/Data 5-UP 5 Ghz 80m N/A 108Mbps 72Mbps World Voice/Data Tabella 11: Tecnologie Wireless

20 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione 12 Lo standard IEEE 80211, la cui prima stesura risale al 1997, è ad oggi il protocollo per le wireless LAN communications maggiormente consolidato In esso sono contenute le specifiche di diverse tecnologie wireless che, oltre ad operare tutte nelle bande libere a 24 e 5 GHz, condividono il medesimo livello MAC su due diverse specifiche per il livello fisico ossia FHSS (Frequency Hopping Spread Specrtum) e DSSS (Direct Sequence Spread Spectrum) HIPERLAN/2 è invece la soluzione europea per una broadband wireless LAN capace di raggiungere i 54Mbps ed utilizza un protocollo orientato alla connessione (connection oriented protocol) ovvero un protocollo in cui le trasmissioni dati avvengono solo a valle di operazioni di negoziazione del canale Dalla fusione ragionata di HIPERLAN/2 e 80211a nasce lo standard 5-UP che mira al raggiungimento di un data rate di circa 100 Mbps Ad incoraggiare invece l introduzione di una tecnologia di natura diversa quale è Bluetooth è stata l esigenza di una tecnologia capace di eliminare i cavi tra un certo numero di dispositivi, eterogenei per tipologia e casa produttrice, situati in una regione circoscritta pur mantenendosi economica e user friendly: è proprio nella estrema semplicità sia architetturale sia di utilizzo che risiede la chiave di un successo tale che nel 2007 il 65% dei telefoni cellulari, il 44% dei PDA e il 36% dei notebook sarà prodotto con l interfaccia Bluetooth integrata [rndbncsd04] Nima Ahmadinejad, Business Development Director di Belkin, sostiene che Bluetooth è così popolare perché è un protocollo grazie al quale i dispositivi palmari potranno servire per nuove funzioni e comandi Lo scopo finale di Bluetooth è di fare in modo che un solo dispositivo palmare possa sostituire il telecomando del garage e del televisore, il puntatore laser del mouse, il modem per collegamenti commutati, e allo steso tempo sia abbastanza potente da funzionare come un PDA che può sincronizzare via radio la posta elettronica con i PC,

21 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione 13 navigare in Internet e comandare il lettore di DVD, il forno a microonde e il climatizzatore Previsioni tanto ambiziose trovano giustificazione in una serie di fondamentali vantaggi offerti dalla tecnologia Bluetooth: 1 richiede una quantità ridotta di risorse energetiche (less power consumptive technology); 2 lavora nella banda libera ISM 1 a 24 Ghz; 3 prevede bassi costi di produzione e vendita dei dispositivi; 4 è particolarmente adatta al last meter access [MG00] Inoltre una gestione deterministica dell assegnazione del canale (TDD - Time Division Duplex) fa sì che essa possa essere validamente utilizzata a supporto di applicazioni real-time Sulla scorta di una tale popolarità e di previsioni di mercato tanto incoraggianti, il presente lavoro di tesi propone uno studio della affidabilità di Bluetooth nell ottica dependability oriented illustrata al Paragrafo 12 1 Industrial, Scientific, Medical

22 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione La tecnologia Bluetooth: concetti generali Il termine Bluetooth identifica l aderenza di un prodotto ad uno standard industriale sviluppato da Ericsson e in seguito formalizzato dal Bluetooth Special Interest Group (SIG) costituito inizialmente da Sony Ericsson, IBM, Intel, Toshiba, Nokia e a cui si sono poi aggiunti negli anni altri grossi nomi del settore Il protocollo opera nella banda libera ISM in cui è elevato il rischio di collisioni: per attenersi alle normative imposte sulla modalità di utilizzo della banda a disposizione (tecniche di trasmissione a spettro espanso, limite massimo e minimo alla potenza di trasmissione), Bluetooth utilizza uno schema di trasmissione FHSS in cui il segnale modulante modula una frequenza non fissata ma variabile in maniera pseudo casuale tra 79 valori possibili La politica di accesso al canale è invece, come già anticipato, di tipo TDMA-TTD e si basa su slot temporali della durata nominale di 625µsec In generale uno slot consente la trasmissione di un intero pacchetto in modo tale che esso possa essere integralmente trasmesso alla stessa frequenza ma è anche possibile che alcuni pacchetti occupino più di uno slot Bluetooth consente la trasmissione sia di traffico dati su canali ACL (Asynchronous Connection Link) sia di traffico voce su canali SCO (Synchronous Connection Link) Dispositivi connessi in rete tramite Bluetooth costituiscono una piconet, ovvero una rete composta da un numero massimo di otto devices coordinati da un unico master che ha l onere di orchestrare le comunicazioni all interno della rete stessa I dispositivi soggetti alle direttive del master prendono il nome di slaves e possono essere al più sette all interno della medesima piconet In una piconet sono contemplate trasmissioni sia punto punto sia multipunto però i dispositivi slave possono comunicare tra loro non direttamente ma soltanto attraverso il nodo master che, inoltre, ha il compito di

23 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione 15 stabilire a quale dispositivo slave spetti il diritto di trasmettere: per evitare che due o più slave trasmettano contemporaneamente generando collisioni il master esegue procedure di polling L alternanza nell accesso al canale è illustrata in Figura 13 f n f n + FH 1 n + FH 2 f Master Packet Packet Time ( Slave µ Packet t Figura 13: Alternanza nell accesso al canale tra il master ed uno slave Due o più piconet possono interconnettersi, fino ad un massimo di dieci, a formare una scatternet (cfr Figura14): l interconnessione avviene grazie ad un dispositivo che funge da brigde e che, evidentemente, non potrà essere master per più di una piconet Figura 14: Bluetooth scatternet In un ottica di risparmio energetico è consentito ai dispositivi slave di configurarsi quali unità passive della rete: oltre allo stato active, infatti,

24 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione 16 sono contemplate condizioni di sniff, park, hold in cui un dispositivo può permanere se non coinvolto in connessioni attive Affinché due o più device possano connettersi è necessaria una procedura di mutua autenticazione Un dispositivo che voglia diventare master di una piconet contatta altri device eventualmente presenti, e in stato discoverable, inviando il proprio indirizzo fisico e dando il via ad una procedura che prende il nome di inquiry La procedura con cui il master instaura la connessione vera e propria con uno slave prende invece il nome di pairing ed è seguita da una fase per la definizione di una chiave di decrittaggio detta link key Al fine di garantire la connettività tra dispositivi di produttori differenti, lo standard definisce non solo le regole della comunicazione radio, ma anche del protocollo di comunicazione che rispecchia una struttura stratificata in cui i servizi offerti dal livello i-simo sono resi disponibili al livello i+1-esimo e la comunicazione logica avviene tra livelli omologhi (cfr Figura15) PPP Figura 15: Bluetooth Stack Per favorire l interoperabilità tra devices prodotti da diverse case produttrici il SIG ha inoltre introdotto il concetto di Bluetooth Profile: come si legge dalle specifiche [SIG03] l interoperabilità per un determinato servizio

25 Capitolo 1 Applicazioni dependable per il mobile computing di nuova generazione 17 è garantita se i dispositivi sono conformi alle specifiche del relativo Bluetooth Profile I diversi profili sono organizzati in maniera gerarchica come rappresentato in Figura 16 Ad oggi la tecnologia Bluetooth è supportata da quasi tutti i sistemi operativi più comuni tra cui Linux in tutte le sue distribuzioni, le versioni mobile dei sistemi Microsoft e Windows Xp SP2 Figura 16: Bluetooth Profiles Organization

26 Capitolo 2 Dependability e metodologie di failure data analysis L evolversi delle tecnologie ed il fiorire di scenari applicativi sempre nuovi e complessi ha indotto negli anni numerose rivisitazioni del concetto di dependability nella sua accezione più completa Nel presente capitolo è riportata una breve ricostruzione storica delle diverse interpretazioni oltre che la descrizione dei concetti fondamentali legati all idea di dependability Ad una prima parte meramente descrittiva in cui si illustrano gli attributi di dependability, le minacce all affidabilità di un sistema e le tecniche di dependability improvement, segue una seconda parte incentrata sull analisi dei dati (failure data analysis) per la valutazione dell affidabilità di un sistema Il capitolo si conclude con un caso di studio -presente in letteraturasull analisi, quantitativa e qualitativa, della dependability di un sistema networked 21 Il concetto di dependability nel tempo Requisiti di affidabilità sono diventati negli anni di primaria importanza per un numero sempre crescente di sistemi sottoponendo a continue rivisitazioni l interpretazione del concetto di dependability Nel 1982 Laprie definiva la dependability come the ability of a system to accomplish the tasks (or,equivalently, to provide the service) which are expected to it ; in [AA85] (1985) Avizienis si riferiva alla dependability come the quality of the delivered service such that reliance can justifiably be placed on the service it delivers Nel 2001 ancora Laprie et al [AA01] sintetizzavano il concetto in the ability to deliver service that can justifiably be trusted per poi renderlo più generale nel 2004 [AL04] de- 18

27 Capitolo 2 Dependability e metodologie di failure data analysis 19 finendo la dependability come ability to avoid service failures that are more frequent and more severe than acceptable 211 Sistema, servizio, interfaccia Prima di procedere nella trattazione è necessario chiarire il significato di termini ricorrentemente utilizzato nell arco del presente capitolo quali sistema (1), servizio (2) ed interfaccia (3) 1 Per sistema si intende una qualsiasi entità in grado di interagire con altre entità, siano esse altri sistemi o utenti umani L insieme di entità con cui un sistema è in grado di interagire ne costituiscono l ambiente (environment) Il comportamento (behavior) di un sistema è l insieme delle azioni che esso compie per implementare le funzioni richieste ed è costituito da una successione di stati; 2 Il servizio fornito da un sistema è il suo comportamento così come è percepito da un utente, ovvero da una qualsiasi altra entità che usufruisce del servizio stesso Un servizio corretto, proper service, è un servizio fornito dal sistema conformemente alle specifiche Qualora il servizio dovesse deviare da esse si parla di service failure, o più sinteticamente failure (cfr Paragrafo 223); 3 L interfaccia di un sistema è il confine dello stesso percepibile da un utente L interfaccia su cui viene fornito il servizio prende il nome di service interface 212 Gli attributi di dependability Dalle definizioni di cui al Paragrafo 21 emerge che la di dependability di un sistema non è un concetto semplice a formalizzarsi In realtà essa è

28 Capitolo 2 Dependability e metodologie di failure data analysis 20 un insieme di attributi di qualità (dependability attributes) che assumono singolarmente un enfasi relativa alla natura del sistema cui si riferiscono e al particolare contesto applicativo: Availability L Availability (o anche disponibilità) è sinteticamente definita come la probabilità che un sistema sia pronto in un certo istante t, in formule: A=P(!Failure at t) (21) Più esplicitamente, un sistema è available in un dato istante t se è in grado di fornire un servizio corretto Matematicamente quindi la funzione A(t) è del tipo: 1 if proper service at t A(t) = 0 otherwise (22) e dunque la 21 si riferisce al suo valore atteso, E(A(t)) Una serie di interessanti critiche sono state mosse ad una simile interpretazione del concetto di disponibilità: 1 un sistema potrebbe non essere totalmente disponibile ma comunque continuare ad essere operativo: l availability potrebbe dunque essere interpretata come uno spettro di valori e non in chiave binaria (up or down); 2 la disponibilità di un sistema dovrebbe essere intesa quale funzione della qualità del servizio offerta dal sistema nel tempo e

29 Capitolo 2 Dependability e metodologie di failure data analysis 21 non come un valore medio: secondo la (21) un sistema indisponibile per due secondi al minuto ed uno indisponibile per un intero giorno ogni anno sono caratterizzati dal medesimo valore di availability pur avendo un comportamento sensibilmente diverso Reliability La Reliability R(t) è la misura della continuità di un servizio ovvero la misura dell intervallo di tempo in cui viene fornito un servizio corretto: R(t)=P(!Failure in (0,t)) (23) Più in generale, la distribuzione dell affidabilità di un sistema R(t,τ) è la probabilità condizionale che il sistema funzioni correttamente (proper service) nell intervallo [t,t+ τ], ammesso che fosse correttamente operativo al tempo t [DP]: R(t, τ) = P(no failures in [t, τ] corretto funzionamento in t) (24) Detta F(t) la funzione di distribuzione cumulativa del tempo di fallimento (CDF -Cumulative Distribution Function), unreliability, la funzione R(t) può essere riscritta come R(t)=1-F(t) (25) Il numero di fallimenti di un sistema per unità di tempo è definito come tasso di fallimento, è generalmente indicato con λ(t) e misurato in numero di fallimenti per ora L andamento tipico del tasso dai fallimento per un componente è riportato in Figura 21

30 Capitolo 2 Dependability e metodologie di failure data analysis 22 λ(t) Infant mortality Normal Lifetime Wear Out Period Approximatively constant Figura 21: Andamento del failure rate di un componente t Una tra le relazioni esistenti tra la funzione di distribuzione dell affidabilità ed il tempo è del tipo: R(t)=e λt (26) La 26 è nota come legge di fallimento esponenziale ed afferma che in un sistema a tasso di fallimento costante l affidabilità decresce in maniera esponenziale nel tempo Safety Per safety si intende generalmente l assenza di condizioni di funzionamento che possano portare il sistema a danneggiare gli utenti e/o l ambiente in cui opera; secondo Laprie safety è the absence of catastrophic consequences on the users(s) and the environment [AL04] Matematicamente la funzione safety S(t) è la probabilità che non vi siano guasti catastrofici in [0, t]

31 Capitolo 2 Dependability e metodologie di failure data analysis 23 S(t) = P(!CatastrophicFailures in [0, t]) (27) Sebbene una simile definizione sia universalmente accettata in quanto ben evidenzia gli effetti che potrebbe sortire l utilizzo di un sistema unsafe, nel tempo il concetto di safety ha assunto sempre più i tratti di un concetto relativo in quanto legato alla soggettiva valutazione dei rischi e dell entità dei danni provocati dal sistema Performability Le definizioni di availability e reliability appena discusse, partono dall assunzione che durante il suo ciclo di vita un sistema possa permanere esclusivamente in due stati: il sistema può essere non disponibile (DOWN) oppure può essere disponibile e correttamente funzionante (UP & PROPERLY RUNNING) (cfr Figura 22) Failure Repair Figura 22: Binary state model Questa visione semplicistica dei fatti perde di validità qualora si abbia a che fare con sistemi tolleranti ai guasti (fault-tolerant systems): sistemi del genere infatti, seppure in condizioni di performance degradate, riescono ad operare anche in presenza di fallimenti Il diagramma degli stati per un sistema fault-tolerant sarà allora caratterizzato da

32 Capitolo 2 Dependability e metodologie di failure data analysis 24 un numero di stati superiore a due ovvero da un numero di stati almeno pari al numero dei failure che il sistema è in grado di mascherare La metrica introdotta per valutare le performance del sistema anche a valle dell occorrenza di un fallimento prende il nome di performability a sottolineare il suo legame con aspetti sia di PERFORMance evaluation sia di dependability Maintainability La Maintainability, M(t), è generalmente definita come la capacità di un sistema di poter essere sottoposto a modifiche e riparazioni [AL04]: un sistema manutenibile è, infatti, un sistema che deve poter esser facilmente ripristinato in seguito al verificarsi di un guasto Security Sinteticamente la security è definita da Laprie et al in [JC00] come l assenza di manipolazioni improprie e accessi non autorizzati al sistema Più in dettaglio un sistema sicuro è un sistema in cui coesistano più attributi: availability, opportunamente reinterpretata come la disponibilità del sistema esclusivamente ad utenti autorizzati; confidentiality, intesa come la prevenzione di diffusione non autorizzata di informazioni; integrity, ovvero la prevenzione di alterazioni improprie dello stato del sistema La Figura 23 sintetizza quanto appena descritto

33 Capitolo 2 Dependability e metodologie di failure data analysis 25 DEPENDABILITY Reliability Maintainability Performability Safety SECURITY!"#$"% Availability &"!'("% Figura 23: Attributi di dependability 213 Dependability measures Una stima quantitativa del grado di dependability di un sistema può essere ottenuta procedendo al calcolo di parametri sintetici tra cui quelli riportati e descritti in Tabella 21 Parametro Acronimo Descrizione Mean Time To Crash MTTC Tempo medio per avere un crash del sistema Mean Time Between Crashes MTBC Tempo medio tra due crash successivi del sistema Mean Time to Failure MTTF Tempo medio per il verificarsi di un failure Mean Time Between Failures MTBF Tempo medio tra due failures successivi Mean Number of Instruction to Restart MNIR Numero medio di istruzioni per il ripristino del sistema Mean Time to Repair MTTR Tempo medio necessario a riparare il sistema Mean Down Time MDT Tempo medio per cui il sistema non è funzionante Mean Time Between Errors MTBE Tempo medio tra due errori successivi Tabella 21: Dependability Measures MTTF ed MTTR - graficamente rappresentati in Figura 24- risultano utili, ad esempio, al calcolo dell availability secondo la 28 A(t) = MTTF MTTF + MTTR (28) Con riferimento agli attributi discussi al Paragrafo 213 è possibile an-

34 Capitolo 2 Dependability e metodologie di failure data analysis 26 MTTF MTBF MTTR Operating state Figura 24: MTTF,MTBF,MTTR che fornire un ulteriore interpretazione del tempo di fallimento e del tempo di ripristino in termini rispettivamente di reliability e maintainability media: MTTF = R(t) MTTR = M(t) 22 Dependability threats Le cause per cui un sistema può portarsi in uno stato incoerente, e dunque fallire, sono molteplici e possono manifestarsi in ogni fase del suo ciclo di vita: guasti hardware, errori in fase di progettazione hardware e/o software ed errati interventi di manutenzione sono soltanto alcune tra le possibili sources of failure 221 Faults Un guasto, fault, è uno stato improprio dell hardware e/o del software del sistema derivante dal guasto di un componente, da fenomeni di interferenza o da errori di progettazione E possibile formulare diverse classificazioni dei

35 Capitolo 2 Dependability e metodologie di failure data analysis 27 faults basandosi sulla loro causa (1) (Avizienis 1985 [AA85]), persistenza (2), intenzionalità (3) ed origine (4) 1 A seconda della causa che li ha generati i faults possono essere classificati in: Physical faults, ovvero guasti del sistema derivanti da problemi all hardware, dunque interni, oppure da cambiamenti nelle condizioni ambientali (interferenze, temperatura), dunque esterni; Human faults, ovvero guasti derivanti da errori umani commessi sia in fase di progettazione (design faults) sia in fase di utilizzo (interaction faults) del sistema 2 A seconda della loro persistenza i faults possono essere classificati in: Permanent (hard) faults, ovvero guasti stabili e continui nel tempo Detto t 0 l istante di occorrenza del guasto e t r l istante di ripristino, l intervallo di permanenza in stato failed del componente affetto dal guasto è [t 0, t r ]; Transient (soft) faults, ovvero guasti legati a momentanee condizioni ambientali e che scompaiono definitivamente senza la necessità di alcuna operazione di ripristino Detto t 0 l istante di occorrenza del guasto, l intervallo di permanenza del componente corrotto in stato failed è [t 0, x] con x non prevedibile; Intermittent faults, ovvero guasti che si verificano in corrispondenza di particolari condizioni ambientali (ad esempio per un certo valore del carico) Scompaiono senza alcuna azione di riparazione per poi ricomparire Detto t 0 l istante di occorrenza del guasto, l intervallo di permanenza del componente corrotto in

36 Capitolo 2 Dependability e metodologie di failure data analysis 28 stato failed è [t 0, x] con x distribuito secondo una determinata variabile aleatoria strettamente legata al tipo di guasto La linea di confine tra guasti intermittenti e guasti transienti sta nella possibilità di applicare eventuali azioni di recupero: alla base di guasti intermittenti vi sono solitamente anomalie hardware che possono essere eliminate grazie ad azioni di riparazione o riprogettazione del componente, mentre alla base di guasti transienti vi sono situazioni non recuperabili in tal senso in quanto generalmente l hardware non risulta danneggiato Guasti non permanenti si sono rivelati spesso la maggiore fonte di fallimento per numerosi sistemi; sebbene diversi siano stati i tentativi di formularne un modello, ad oggi non esiste una soluzione universalmente accettata Siewiorek [DP] riporta i risultati di studi (Andrew file systems, VAX-11780,Tandem TNS-II) basati sulla data collection e sui conseguenti goodness-of-fit test al fine di valutare la conformità dell andamento dei guasti ad una determinata distribuzione statistica: per guasti intermittenti si ottengono buoni risultati per una distribuzione esponenziale mentre i guasti transienti sembrano meglio seguire la distribuzione di Weibull 3 A seconda della loro intenzionalità i faults possono essere classificati in: Malicious faults, ovvero guasti introdotti deliberatamente nel sistema con la volontà di alterarne lo stato provocando una sospensione del servizio o anche di accedere ad informazioni riservate; Non malicious faults, ovvero guasti introdotti inconsapevolmente all interno del sistema

37 Capitolo 2 Dependability e metodologie di failure data analysis 29 4 A seconda della loro origine i faults possono essere classificati in: Internal faults, ovvero guasti riconducibili a cause interne al sistema (ad esempio l usura di un componente); External faults, ovvero guasti riconducibili a particolari condizioni esterne che si ripercuotono sul sistema (ad esempio interferenze o radiazioni) Laprie et al in [AL04] propongono una classificazione dei faults che racchiude tutte le precedenti e basata sull individuazione di tre macroclassi parzialmente sovrapposte (cfr Figura 25) Development faults class: include tutte le classi di guasto che possono verificarsi in fase di sviluppo; Physical faults class: include tutte le classi di guasto legate a guasti fisici dell hardware; Interaction faults class: include tutte le classi di guasto derivanti dall interazione del sistema con l abiente esterno 222 Errors Un errore è la parte dello stato di un sistema che può indurre lo stesso al fallimento ovvero a fornire un servizio non conforme alle specifiche (unproper service) La causa di un errore è un fault (cfr Paragrafo 221) Se l errore è opportunamente rilevato esso si dice detected, viceversa se l errore esiste ma non è rilevato si parla di latent error Laprie et al [AL04] propongono una classificazione degli errori basata sulle categorie di fallimenti che essi sono in grado di provocare: errori di tempo e di valore, errori catastrofici e

38 Capitolo 2 Dependability e metodologie di failure data analysis 30 Figura 25: Tassonomia dei faults (Laprie, 2004) non catastrofici, errori consistenti ed inconsistenti E possibile che un fault all interno di uno specifico componente generi errori in più di un componente del sistema: in tal caso si parla di multiple related errors 223 Failures Un fallimento, failure, è definito come l evento in corrispondenza del quale il sistema cessa di fornire un servizio corretto Generalmente un sistema non fallisce sempre alla stessa maniera: le modalità con cui esso può fallire sono definite failure modes ed implicano la non correttezza del servizio secondo diversi punti di vista [AL04]: dominio (1), rilevabilità (2), percezione (3) e severità del fallimento (4) 1 Un servizio s si ritiene conforme alle specifiche se, detto V l insieme dei valori ammissibili e T l intervallo di tempo in cui esso deve essere

39 Capitolo 2 Dependability e metodologie di failure data analysis 31 fornito (deadline), si ha: s = s(v, t) : v V e t T (29) Dal punto di vista del dominio del fallimento è possibile distinguere: Timing Failures (fallimenti nel tempo), ovvero fallimenti per cui un servizio non è conforme alle specifiche in termini di tempo, ovvero se s = s(v, t) : v V e t / T (210) Fallimenti di questo tipo possono essere poi specializzati in early timing failures se il servizio è fornito in anticipo, late timing failures se in ritardo; Content Failures (fallimenti nel valore), ovvero fallimenti in seguito ai quali il contenuto informativo del servizio perviene all interfaccia in maniera non conforme alle specifica: s = s(v, t) : v / V e t T (211) Qualora un sistema fallisca sia nel tempo sia nel valore esso può fornire non correttamente il servizio in diverse modalità, tra cui: halted, il sistema risulta bloccato e dunque il servizio non perviene all interfaccia; lo stato esterno del sistema è costante, pari ad esempio all ultimo valore Un particolare fallimento di questo tipo è il fallimento per omissione del servizio, omission failure,

40 Capitolo 2 Dependability e metodologie di failure data analysis 32 per cui il servizio è a valore nullo e ritardo infinito Un omission failure permanente prende il nome di crash failure erratic, il servizio perviene all interfaccia (delivered service) ma fornisce informazioni incoerenti 2 Dal punto di vista della rilevabilità del fallimento (failure detectability) si distinguono: Signaled Failures (fallimenti rilevati) ovvero fallimenti segnalati a livello utente da un opportuno messaggio di errore; Unsignaled Failures (fallimenti non rilevati) ovvero fallimenti non segnalati a livello utente 3 Dal punto di vista della percezione del fallimento (failure consistency) si distinguono: Consistent Failures (fallimenti consistenti), per cui tutti gli utenti del sistema hanno la stessa percezione del fallimento; Unconsistent Failures (fallimenti inconsistenti), ovvero fallimenti che possono essere percepiti in maniera diversa dagli utenti del sistema Fallimenti di questo tipo sono generalmente indicati come fallimenti bizantini, Byzantine failures 4 Dal punto di vista della gravità del fallimento (failure consequences) si distinguono: Catastrophic Failures (fallimenti catastrofici), ovvero fallimenti le cui conseguenze sono incommensurabilmente più grandi del beneficio prodotto dal servizio fornito in assenza di fallimento;

41 Capitolo 2 Dependability e metodologie di failure data analysis 33 Minor Failures (fallimenti benigni), ovvero fallimenti le cui conseguenze sono dello stesso ordine di grandezza (valutato generalmente in termini di costo) del beneficio prodotto dal servizio fornito in assenza di fallimento Un sistema in cui si manifestano esclusivamente fallimenti benigni è un sistema fail-safe Una stima quantitativa delle conseguenze dei fallimenti induce alla definizione di severità del fallimento, failure severity, strettamente legata al costo necessario per il ripristino, dipendente dal contesto e generalmente espressa in termini della massima probabilità di occorrenza del fallimento stesso che il sistema è in grado di sopportare Una schematizzazione di quanto appena esposto è riportata in Figura 26 Figura 26: Tassonomia dei fallimenti (Laprie, 2004)

42 Capitolo 2 Dependability e metodologie di failure data analysis Propagazione delle minacce: la catena fault, error, failure Fault, error e failure sono legati da una precisa relazione definita in letteratura come patologia del guasto [AL04] e schematizzata in Figura 27 Un fault può degenerare in un errore mediante attivazione (fault activation, ACT): in tal caso il guasto si dice attivo (active), altrimenti è dormiente (dormant, DF) Un guasto attivo può essere un guasto interno oppure un guasto esterno L attivazione di un guasto provoca la transizione del sistema da uno stato di corretto funzionamento (correct behavior) ad uno stato improprio (error); la rilevazione di un errore e le opportune operazioni di ripristino (EDP) riportano il sistema ad operare in maniera corretta Un errore può degenerare in un fallimento mediante propagazione all interfaccia utente (EPR); un errore che non porta il sistema nello stato failure è un errore latente (LE) )*+,-/-01* :92;*<* :=7 8 Correct Behavior Error Failure N2-/-01*-OP 4N7 >?@ABCD EBFGDH I>EJ K B DLCD M@@?@H I MJ K N2-/-01*-OP 4N7 QO-O/-OP*3P :92/ORROP 4 Q:7 8 Figura 27: Patologia dei guasti Un fallimento si ha dunque per propagazione di un errore e si verifica allorquando l errore si manifesta all interfaccia del sistema alterando la correttezza del servizio: per un qualsiasi altro sistema o componente che usufruisca del servizio corrotto, il fallimento così generato si configura quale

43 Capitolo 2 Dependability e metodologie di failure data analysis 35 guasto esterno (external fault) e si parla, più precisamente, di propagazione esterna (external propagation) Per propagazione interna, (internal propagation), si intende invece la generazione di errori a cascata all interno di uno stesso componente Nell economia generale dello studio della dependability di sistemi distribuiti, i fenomeni di propagazione esterna assumono un peso rilevante in quanto rendono spesso difficile l individuazione del sistema remoto responsabile del fallimento In Figura 28 è illustrato il meccanismo della propagazione con riferimento al caso particolare di sistemi in cascata L attivazione abcdefg heijg klmnopmnqr STUVTWXWYZ[ tuvtwxwyzwyx{ }~x STUVTWXWYZ\ STUVTWXWY][ ^ `_ ^ `_ Š ^ `_ ^ `_ ^ `_ rm rp SF Ef ƒ q p pmnqr s ˆ m rp ƒ q p pmnqr System interface SF qœ qr rm pn Ž System A ˆ m rp ƒ q p pmnqr SF m Œ pn Ž Ef ˆ m rp pž m System B Figura 28: Propagazione esterna dei guasti di un fault dormiente nel sistema A risveglia un errore, prima latente, nel componente A1; per via di fenomeni di propagazione interna, l errore perviene all interfaccia del componente stesso portandolo al fallimento (CF, Component Failure) ed inducendo - a mezzo di una propagazione esternal alterazione del servizio offerto al componente a valle (A2) a cui detto fallimento si presenta quale guasto esterno (EF,External Fault) Attraverso A2 le minacce raggiungono l interfaccia del sistema A provocandone il fallimento (SF, System Failure) e ripercuotendosi sul sistema B per via di fenomeni di propagazione esterna sotto forma di guasto esterno (EF)

44 Capitolo 2 Dependability e metodologie di failure data analysis Dependability means Le tecniche per incrementare il grado di dependability di un sistema sono diverse e si differenziano per il modo con cui si relazionano all occorrenza di un fault La scelta della particolare strategia da utilizzare è inesorabilmente influenzata dalla natura del sistema e dunque da quale sia il dependability attribute che si è interessati a massimizzare 231 Fault avoidance La fault avoidance, o anche fault intolerance, è una tecnica orientata esclusivamente a minimizzare la probabilità di occorrenza dei fallimenti Le più elementari tecniche di fault avoidance si basano sull utilizzo di componenti altamente affidabili -con riferimento all hardware- e sulla conduzione di capillari attività di testing -con riferimento al software- inducendo un sensibile aumento dei costi di messa in esercizio del sistema In alcuni casi possono essere utilizzate tecniche di fault avoidance per scongiurare un particolare tipo di fallimento: ad esempio la riduzione del fan-out delle porte logiche riduce la dissipazione di potenza e dunque riduce la probabilità che si verifichino hard failures Ad ogni modo anche la più complessa strategia di fault avoidance non può scongiurare del tutto l occorrenza di fallimenti che quindi non saranno tollerati dal sistema, da qui fault intolerance 232 Fault tolerance Le tecniche di fault tolerance mirano alla minimizzazione delle conseguenze dei guasti sul sistema e dunque ad evitare che essi possano degenerare in fallimenti (failure avoidance) Un sistema fault tolerant è dunque un sistema in grado di continuare ad essere operativo, pur se eventualmente in condi-

45 Capitolo 2 Dependability e metodologie di failure data analysis 37 zioni degradate, nonostante l occorrenza di guasti Strategie di tolleranza ai guasti sono generalmente articolate in due passi (cfr Figura 29): 1 Error detection; 2 Error treatment e System recovery Figura 29: Strategie di tolleranza ai guasti (Laprie, 2004) Nella prima fase si procede alla scoperta di eventuali errori nel sistema e alla loro segnalazione Laprie et al [AL04] individuano due possibili strategie di detection: Concurrent Detection che ha luogo durante il normale funzionamento del sistema e dunque durante il delivering dei servizi; Preemptive Detection che ha luogo durante i periodi di sospensione del servizio e mira all individuazione di eventuali errori latenti nel sistema Il secondo passo consiste nel ripristino del normale funzionamento del sistema attraverso la rimozione dell errore dal sistema, error treatment, ed un

46 Capitolo 2 Dependability e metodologie di failure data analysis 38 insieme di operazioni mirate ad evitare che lo stesso possa attivare dei fault oppure che faults già verificatisi possano essere riattivati, fault handling Come illustrato in Figura 29, la rimozione dell errore può avvenire in tre diverse modalità: Rollback: consiste nel riportare il sistema all ultimo stato stabile in cui permaneva prima dell individuazione dell errore, chekpoint; Rollforward: consiste nel riportare il sistema senza errori in un nuovo stato; Compensation: si utilizza quando il sistema è dotato di componenti ridondanti a sufficienza per poter mascherare l errore Il fault handling, ancora secondo Laprie [AL04], si articola invece nei seguenti passi: Diagnosis, ovvero l individuazione dell errore sia in termini di locazione sia di istante di occorrenza; Isolation, ovvero la procedura di esclusione del componente fallito dal resto del sistema in modo da evitare che possa corrompere la fornitura di altri servizi; Reconfiguration, ovvero la riassegnazione dei task in corso al momento dell errore a componenti integri; Reinitialization, ovvero il ripristino totale del normale comportamento del sistema mediante l aggioramento delle informazioni modificate dalle operazioni precedenti

47 Capitolo 2 Dependability e metodologie di failure data analysis 39 Generalmente alle procedure di fault handling seguono operazioni di manutenzione correttiva, corrective maintainance, per riparare -off-line- i componenti isolati perché guasti 2321 Tecniche di fault tolerance La tolleranza ai guasti è nella maggior parte dei casi ottenuta grazie all utilizzo di tecniche di ridondanza nelle sue due possibili realizzazioni: ridondanza spaziale, ossia l utilizzo di componenti hardware e software replicati in grado di sostituire il componente guasto; ridondanza temporale, ossia l esecuzione ripetuta di determinate operazioni -o di sequenze di operazioni- particolarmente utile nel caso di guasti transienti La più elementare forma di ridondanza spaziale è certamente la replicazione che prevede l utilizzo di componenti gemelli e la valutazione della correttezza dello stato del sistema mediante aggiudicazione Una strategia di questo tipo consente di rilevare gran parte dei guasti relativi ai singoli componenti del sistema ma non quelli del componente aggiudicatore che viene dunque definito un single point of failure E evidente che al crescere del numero N delle repliche (N-modular redundancy, NMR), si assiste ad una proporzionale crescita dei costi ma anche una maggiore affidabilità nelle decisioni che, per ogni valore di N (per N = 3 l architettura è nota con il nome di Triple Modular Redundancy, TMR), sono prese a maggioranza secondo la politica del N 1 out-of-n) da un voter V Per N comunque elevato V resta però il single point of failure dell intero sistema: il problema è noto in letteratura come il Who shall watch over the guardians? e resta un pro-

48 Capitolo 2 Dependability e metodologie di failure data analysis 40 blema mai completamente risolvibile Una stima quantitativa dell efficacia delle tecniche di tolleranza ai guasti prende il nome di coverage 2322 Stati di un sistema fault tolerant Dal Paragrafo 232 emerge che un sistema tollerante ai guasti è un sistema che è in grado di funzionare anche al manifestarsi di guasti A seconda del modo in cui esso reagisce ad un fault può pervenire ad una serie di diverse condizioni di funzionamento che sono sintetizzate nel diagramma degli stati di Figura 210 Figura 210: Diagramma degli stati di un sistema fault tolerant Il diagramma evidenzia due stati principali, operational e failed, a loro volta organizzati in maniera gerarchica Lo stato operational consiste di due sottostati: recovering, in cui il sistema è attivo ma impegnato nell attuazione di procedure di recovery, oppure ready ovvero funzionante Un sistema funzionante può a sua volta essere accessible se è in grado di rispondere alle

49 Capitolo 2 Dependability e metodologie di failure data analysis 41 richieste degli utenti, o inacessible se, ad esempio, è funzionante ma guasti della rete gli impediscono di soddisfare le richieste Un organizzazione analoga è prevista per lo stato failed: un sistema può essere dead, se non è stato in grado di ripristinare il suo funzionamento in seguito ad un guasto, oppure under repair se è al momento sottoposto a manutenzione Se dopo le azioni di riparazione è possibile ripristinare lo stato del sistema antecedente al fallimento allora esso si dice in stato recoverable, altrimenti unrecoverable 233 Fault removal Le tecniche di fault removal mirano all individuazione degli errori ed alla rimozione di eventuali guasti Esse possono essere messe in opera sia durante lo sviluppo del sistema, Fault removal during development (1), sia durante il suo normale utilizzo, Fault removal during use (2) 1 La rimozione dei guasti in fase di sviluppo si articola in tre fasi : verification, in cui si procede a valutare la conformità del comportamento del sistema a specifiche preassegnate; diagnosis, in cui si procede ad identificare la natura di eventuali errori; correction, in cui si procede alla correzione degli errori evidenziati in fase di diagnosi e dopo la quale si ripete la fase di verifica per accertarsi dell avvenuta rimozione (validation) Il problema della verifica può essere affrontato in diversi modi come sintetizzato nello schema di Figura 211 Se la verifica viene effettuata sul sistema non in esercizio si parla di static verification, al contrario di dynamic verification La verifica dinamica avviene fornendo al sistema degli input, reali o simbolici, ed

50 Capitolo 2 Dependability e metodologie di failure data analysis 42 Figura 211: Strategie di verifica (Laprie, 2004) osservando la conformità delle uscite alle specifiche preassegnate: una verifica di questo tipo prende generalmente il nome di testing E evidente che qualora si voglia sottoporre il sistema ad input reali, non è possibile effettuare un testing completamente esaustivo e pertanto si procede alla generazione dei casi di test (test patterns) in maniera deterministica, ovvero selezionando a priori gli ingressi da fornire al sistema, oppure in maniera random In quest ultimo caso la distribuzione ed il numero degli ingressi da fornire al sistema è scelto in accordo al fault model del sistema stesso Osservare gli output e stabilire se il comportamento del sistema è conforme o meno alle specifiche costituisce il problema dell oracolo (oracle problem, cfr Figura 212) Ÿšž œ œ š œ ª Ÿ «žš œ œ žœÿÿ ž œ Figura 212: Fault Removal During Development

51 Capitolo 2 Dependability e metodologie di failure data analysis 43 2 La rimozione dei guasti durante il normale utilizzo del sistema consiste in azioni di manutenzione preventiva e/o correttiva 234 Fault forecasting Le tecniche di fault-forecasting, letteralmente previsione dei guasti, forniscono mezzi per aumentare il livello di confidenza che può essere riposto nella capacità del sistema di fornire un servizio conforme alle sue specifiche [JC95] Esistono due diversi approcci, non in contrasto tra loro, per realizzare fault-forecasting: approccio deterministico o qualitativo, i cui metodi mirano a comprendere quali siano gli effetti dei guasti sul malfunzionamento del sistema; approccio probabilistico o quantitativo, i cui metodi mirano a stimare gli attributi di dependability del sistema Generalmente è necessario combinare i due approcci per ottenere stime affidabili soprattutto nel caso di sistemi complessi 24 La failure data analysis L efficacia delle tecniche di dependability enhancement descritte finora presuppone un adeguata conoscenza del comportamento del sistema: la caratterizzazione statistica dei failure modes, accanto alla formulazione di modelli realistici, incrementa la predicibilità del sistema stesso facilitando l applicazione di mirate azioni preventive e/o correttive La failure data analysis, attraverso l esame di dati relativi ai fallimenti, si configura quale strumento per la valutazione della dependability di un sistema fornendo informazioni

52 Capitolo 2 Dependability e metodologie di failure data analysis 44 utili sia alla costruzione di un modello di riferimento sia alla progettazione di nuovi sistemi RIyer et al in [RK00] evidenziano come ai fini dell analisi della dependability di un sistema assuma rilevante importanza il binomio costituito dalla fase del ciclo di vita in cui si è scelto di operare e dal particolare strumento di valutazione utilizzato In fase di progettazione, design phase, lo studio dell affidabilità del sistema può essere condotto utilizzando software di simulazione: il sistema viene volontariamente sottoposto a situazioni di errore (simulated fault-injection) con il duplice obiettivo di individuare eventuali dependability bottlenecks e di stimare la coverage dei meccanismi di fault tolerance I feedback derivanti dallo studio delle reazioni del sistema risultano particolarmente utili ai system designers in un ottica di riprogettazione cost-effective A progettazione ultimata, viene generalmente rilasciata una versione prototipale del sistema affinché esso possa essere sottoposto alle dovute attività di testing In questa fase il sistema viene sollecitato con profili di carico ad hoc (controlled workloads) per poter studiare le sue reazioni a faults reali (physical fault-injection), le sue capacità di recupero in seguito a situazioni di errore (recovery capabilities) e l efficacia delle tecniche di detection (detection coverage) Uno studio di questo tipo fornisce informazioni circa il failure process del sistema (cioè la sequenza di stati che esso attraversa dal momento in cui si verifica l errore fino all eventuale recovery) ma non consente di valutare misure di dependability quali MTTF, MTTR dal momento che saranno stati considerati esclusivamente fault artificiali E importante sottolineare che, a differenza di quanto accade in fase di progettazione, in fase prototipale è possibile iniettare guasti anche a livello software In fase di normale utilizzo del sistema, e dunque quando esso è ormai completamente operativo, è possibile valutarne la dependability mediante

53 Capitolo 2 Dependability e metodologie di failure data analysis 45 un analisi sul campo ovvero analizzandone il comportamento in risposta a profili di traffico reali: un approccio di questo tipo, noto in letteratura come field failure data analysis, consente di ottenere informazioni relative esclusivamente agli errori rilevati durante il periodo di osservazione e la caratterizzazione statistica che se ne può dedurre pecca in termini di generalità vista l infinità varietà di situazioni reali in cui il sistema può trovarsi Ad ogni modo, secondo RIyer [RK00] there is no better way to understand dependabilty characteristics of computer systems (including networked systems) than by direct measurements and analysis : il Paragrafo 241 illustra i dettagli di un simile approccio 241 Field failure data analysis L analisi della dependability di un sistema basata su un approccio di tipo measurement-based si articola in quattro fasi successive: elaborazione dei dati (1), identificazione del modello e stima dei parametri (2), soluzione del modello (3), analisi del modello e misure (4) (cfr Figura 213) Figura 213: Fasi della field failure data anlysis (Iyer, 2000) 1 Per consentire l elaborazione dei dati è necessario che essi siano stati preventivamente raccolti mediante operazioni di logging (automatico o manuale) in una quantità tale da poter far sì che i risultati dell analisi assumano rilevanza statistica: in altre parole, vista la bassa frequenza

54 Capitolo 2 Dependability e metodologie di failure data analysis 46 ±µ ² ³µ ± ²³ µµ µ ± ¹³ º³» ¼³ ½ µµ µ ½³¾¼µ ¹± Figura 214: Esempio di log entry di fallimento dei moderni sistemi, è necessario che le attività di misurazione siano condotte su un arco temporale sufficientemente lungo La fase di elaborazione dei dati in senso stretto, data processing, consiste nella opportuna manipolazione del file di log (a), nella classificazione degli errori (b), nell estrazione dei dati di interesse e nell applicazione di algoritmi di coalescenza (c) 1a Generalmente le informazioni contenute nei file di log (in particolare nel caso di logging automatico on-line) sono ridondanti e riportate in formati differenti che è bene uniformare al fine di facilitare le successive operazioni di calcolo; 1b La classificazione degli errori non è una classificazione universale ma varia a seconda del sistema in esame Con riferimento ad un networked system, ad esempio, è possibile classificare gli errori in base alla loro origine e quindi individuare errori legati alle singole macchine (machine-related) o a problemi della rete (network-related) 1c I dati necessari all analisi vengono estratti dal file di log e riscritti in un flat format in modo tale che ogni entry contenga soltanto le informazioni necessarie all analisi; un esempio è riportato in Figura 214 Per evitare poi che l analisi sia polarizzata da più entry relative allo stesso errore e riportate sul log file a distanza ravvicinata è necessario applicare algoritmi di coalescenza ovvero algoritmi

55 Capitolo 2 Dependability e metodologie di failure data analysis 47 in grado di compattare in un unico evento (tupla) le entry il cui timestamp rientri in un certo intervallo, più esplicitamente: if((errortype)==(typeofpreviouserror)&&(timeawayfrompreviouserror)<delta) put this entry in tuple being built; else start a new tuple; La scelta del valore di è critica in quanto può generare fenomeni di collisione se troppo piccolo, di troncamento altrimenti 2 Avendo a disposizione i dati nel formato e nella quantità opportuni, è possibile in questa fase cominciare ad individuare il modello del sistema e a valutarne i parametri pure se in via preliminare I modelli generalmente più utilizzati in questa fase sono le catene di Markov, modelli ciclostazionari che evidenziano la dipendenza dal carico e modelli statistici di correlazione error/failure I valori tipicamente stimati fanno riferimento alla frequenza di errori e fallimenti (TTE, TTF) e all availability del sistema; strumenti di calcolo statistico (ad esempio SAS 1 ) risultano particolarmente utili a questo punto dell analisi Va detto poi che per sistemi networked è in questa fase che si procede alla differenziazione del comportamento dei singoli host dal comportamento dell intero dominio (cfr Paragrafo 25) 3 In questa fase si procede, se necessario, alla soluzione del modello al fine di ottenere risultati precisi relativamente alla reliability e all availability del sistema con l ausilio di strumenti di modellazione e valutazione delle performance (ad esempio SHARP E [Tri02]) Per sistemi networked assume importanza centrale l analisi della propagazione dei guasti all interno della rete e la valutazione dei parametri ad essa correlati 1

56 Capitolo 2 Dependability e metodologie di failure data analysis 48 4 A valle del calcolo dei parametri più significativi si procede, in questa fase, all interpretazione dei risultati adottando metodi di analisi che possono significativamente variare a seconda del sistema e degli scopi dell analisi stessa 25 Un caso di studio: Windows NT In questa sezione si riporta l applicazione delle metodologie discusse al Paragrafo 24 ad una rete locale (LAN, Local Area Network) di 68 workstations WindowsNT [RK00] In Tabella 22 sono sintetizzati i parametri relativi alla sessione di test Tipo di macchine Mail Servers, Windows NT 40 Numero di macchine 68 Periodo di raccolta 6 mesi Fallimenti rilevati Reboots Tabella 22: Parametri del test Raccolta dei dati: event logging in WindowsNT La modalità di raccolta dei dati per cui si è optato in questa sessione di test è la modalità di logging automatico e dunque utilizza il meccanismo di cattura degli eventi offerto dal sistema operativo (SO) che, nel caso di WindowsNT, è gestito da un apposito Event Logging Subsystem Per la cattura di eventi generati da applicazioni di utente sono disponibili apposite API (Application Programming Interface) mentre per eventi generati dall Executive (componente del SO WindowsNT che viene eseguito in modalità privilegiata) la cattura è ad opera di un apposito I/O manager WindowsNT prevede la classificazione degli eventi in tre gruppi:

57 Capitolo 2 Dependability e metodologie di failure data analysis 49 1 Application events, ovvero gli eventi generati dalle applicazioni in esecuzione su macchine NT (ad esempio MTA, message transfer Agent); 2 System events, ovvero gli eventi generati dai componenti di WindowsNT (ad esempio il NETLOGON service); 3 Security events, ovvero gli eventi generati da operazioni di login/logout degli utenti o di verifica dei diritti di accesso Il sistema di logging associa ad ogni evento le seguenti informazioni: Date and time; Event Severity; Event id; Event Source; Machine name; Event specific information Estrazione dei dati, classificazione degli errori e coalescenza Dal momento che i dati di interesse per il test in esame sono relativi esclusivamente ai reboots delle workstations, l operazione di estrazione dei dati consiste nell individuare le voci relative al reboot in senso stretto ma anche agli eventi ad esso correlati, prominent events La selezione di eventi di questo tipo avviene isolando le voci relative ad eventi che precedono il reboot nell arco di un ora; una scelta di questo genere è nella maggior parte dei casi sufficiente a spiegare dettagliatamente la causa del reboot ma in determinate circostanze il numero di eventi selezionato basta a fornire soltanto una descrizione di alto livello del problema Nel caso in cui fossero stati registrati

58 Capitolo 2 Dependability e metodologie di failure data analysis 50 più eventi di reboot nell arco di un ora le voci ad essi relative vengono collassate nell unica tupla corrispondente all ultimo evento (reboot più giovane) In Tabella 23 sono riportati i risultati relativi alla suddivisione degli eventi di reboot in base alla natura dei prominent events: Categoria Frequenza Percentuale Total Reboots Hardware or firmware problems Connectivity problems Crucial Application failures Problem with a sw component 42 4 Normal shutdowns 63 6 Normal reboots Unknown Tabella 23: Breakup dei reboot in base ai prominent events (Iyer, 2000) Sulla scorta dei risultati in Tabella 23 è possibile fare interessanti considerazioni preliminari sul comportamento del sistema: 1 Nel 29% dei casi i reboots non possono essere classificati (unknown): ciò a dire che non si dispone di informazioni sufficenti a risalire alla causa del problema; 2 Gli errori legati a problemi hardware sono in piccola percentuale (circa 10%) e dunque gran parte dei fallimenti è software related ovvero da imputarsi a problemi di natura software; 3 Una percentuale significativa degli errori (circa il 22%) è lagata a problemi di connettività: questo comportamento era prevedibile dal momento che il workload in esecuzione sulla rete è fortemente I/O intensive E importante però notare che problemi di questo tipo potrebbero derivare dalla propagazione di errori propri di altre macchine del dominio: una stima più precisa della quantità di errori riflessi non è ancora ottenibile in questa fase di valutazione preliminare

59 Capitolo 2 Dependability e metodologie di failure data analysis 51 Analisi e modellazione del comportamento di un host Nell ambito di un sistema networked è bene riuscire a comprendere il comportamento dei singoli host al fine di poter valutare parametri locali quali ad esempio Down times, Up times (1) e l Availability(2) 1 Detti R i la i sima istanza di reboot registrata sul log; T Ri il timestamp relativo al reboot i simo; E [j] la j sima istanza di un evento generico registrata sul log; T E[j] il timestamp relativo all evento j simo; Event[n] il vettore degli eventi compresi tra R i ed R (i+1) ; Event[m] il vettore degli eventi compresi tra R (i 1) ed R (i) ; i tempi di attività ed inattività sono stati calcolati come segue: UpTime[i] = T Ri T E[n 1] i = 1n Reboots DownTime[i] = T E[m 1] T Ri i = 1n Reboots UpTime = n Reboots i=1 U pt ime[i] DownTime = n Reboots i=1 DownT ime[i] In Tabella 24 sono riportati i valori dei tempi di up e down 2 La percentuale di tempo per cui un host è available è stata calcolata secondo la 212

60 Capitolo 2 Dependability e metodologie di failure data analysis 52 Up time Down time Item Value Value Number of entries Maximum 852 days 1576 days Minimum 1 hour 1 second Average 1182 days 1143 minutes Standard deviation days 1586 hours Tabella 24: Statistiche sui tempi di up e down A = UpTime UpTime + DownTime (212) Item Value Number of machines 66 Maximum 999 Minimum 8939 Average 9935 Standard deviation 152 Tabella 25: Statistiche sulle percentuali di Availability I risultati relativi all availability (cfr Tabella 25) sono coerenti con l interpretazione della stessa di cui alla 22 ossia indicano la percentuale di tempo per cui il sistema è operativo ma non assicurano che per l intera durata dell intervallo il sistema abbia fornito un servizio corretto Al fine ottenere una stima più accurata dell availability si procede alla formulazione di un modello del sistema (nella fattispecie un singolo host) pervenendo al diagramma degli stati di Figura 215 in cui ogni stato rappresenta un livello di funzionalità della macchina I valori riportati sugli archi del diagramma indicano le probabilità di transizione tra gli stati e sono state valutate effettuando la suddivisione del file di log in finestre temporali di ampiezza pari a un ora

61 Capitolo 2 Dependability e metodologie di failure data analysis 53 Figura 215: Modello a stati finiti di un singolo host (Iyer, 2000) Analisi e modellazione del comportamento del dominio L analisi del sistema dal punto di vista del intero dominio è finalizzata alla comprensione delle interazioni tra i singoli hosts e all individuazione di eventuali bottlenecks all interno della rete Per reboot del dominio si intende il reboot di almeno una delle macchine che ne fanno parte e dunque la probabilità che esso si verifichi è data dalla 213 P(R domain ) = n machines i=1 P(R i ) (213) Analogamente a quanto visto con riferimento ad un singolo host, anche nel caso dell intero dominio è stato necessario formulare un modello (cfr Figura 216) per ottenere stime sufficientemente accurate dei parametri di dependability L interpretazione degli stati individuati dal modello è riportata in Tabella 26

62 Capitolo 2 Dependability e metodologie di failure data analysis 54 Figura 216: Modello a stati finiti del dominio (Iyer, 2000) State Name PDC BDC MDBC PDC+BDC PDC+MBDC F Meaning Primary Domain Controller rebooted One of Backup Domain Controller rebooted Many Backup Domain Controller rebooted PDC+ 1 BDC rebooted PDC+ many BDC rebooted Functional Tabella 26: Interpretazione degli stati del modello del dominio (Iyer, 2000)

63 Capitolo 2 Dependability e metodologie di failure data analysis 55 Osservando le probabilità di transizione riportate sul diagramma di Figura 216 è possibile trarre alcune importanti conclusioni: Una percentuale significativa di transizioni avvengono dallo stato F allo stato MDBC ed è dunque ragionevole pensare che vi sia correlazione tra i guasti dei vari BDC (Backup Domain Controller); La maggior parte delle transizioni in uscita dallo stato PDC sono indirizzate allo stato F a significare che il PDC (Primary Domain Controller) riesce a concludere le azioni di ripristino prima che possano verificarsi fenomeni di propagazione e/o che i problemi relativi al PDC non vengono per loro natura propagati ai BDCs Da quanto appena discusso e dall analisi del grafico di Figura 217, che illustra la distribuzione dei tempi di inter reboot, è possibile evidenziare l entità dei fenomeni di propagazione all interno del sistema nel suo complesso Figura 217: Distribuzione dei tempi di inter-reboot Lo studio di detti fenomeni è stato condotto effettuando la seguente

64 Capitolo 2 Dependability e metodologie di failure data analysis 56 classificazione dei prominent events che hanno generato reboot del dominio ( e dunque di almeno uno dei singoli host): local machine related problems, ovvero problemi relativi solo alla macchina che è stata riavviata; remote machine related problems, ovvero problemi di connettività legati ad errori su una macchina remota; general network related problems, ovvero problemi di rete di cui non si conoscono ulteriori dettagli Informazioni circa gli eventi di reboot sono state scritte sul file di log di un singolo in maniera tale da contenere i dettagli di tutti gli eventi verificatisi all interno del dominio nell arco di un ora: in altre parole, il file di log di un singolo host contiene non solo informazioni riguardanti l host stesso ma anche relative a tutte le altre macchine del dominio e alla loro attività nelle ore che hanno preceduto e seguito il reboot Per i dettagli sul formato utilizzato per la registrazione delle informazioni si veda [RK00] al Paragrafo 9 A valle della processazione delle informazioni così raccolte si evince che la maggior parte dei fallimenti del dominio è dovuta a problemi dei singoli host e non a fenomeni di propagazione sebbene vi sia una discreta percentuale di fallimenti la cui fonte è risultata non classificabile (unknown)

65 Capitolo 3 Failure Data Analysis di reti Bluetooth Il trend sempre crescente dell utilizzo di Bluetooth in contesti applicativi critici suggerisce la necessità di un analisi sul campo della sua affidabilità Obiettivo centrale di un simile studio è la caratterizzazione statistica del suo comportamento in termini di affidabilità e la formulazione di strategie utili agli sviluppatori di applicazioni mobili che possano dirsi dependable Il presente capitolo, nella sua prima parte, illustra la metodologia di generazione e raccolta dei dati, l architettura di supporto ed il software di emulazione dei profili di traffico Le ultime sezioni concentrano l attenzione sugli algoritmi di filtraggio dei dati e coalescenza 31 Obiettivi e metodologie Sebbene Bluetooth si stia avviando a divenire la tecnologia maggiormente utilizzata nell ambito delle comunicazioni wireless a corto raggio, ancora poco si conosce delle sue prestazioni in termini di affidabilità e di utilizzo del canale Il presente lavoro di tesi -che si inserisce nel contesto di un attività di ricerca già avviata- si propone, mediante l analisi dei dati relativi ai fallimenti, di fornire una caratterizzazione sperimentale del comportamento di reti Bluetooth al fine di comprenderne il grado di dependability e rendere dunque possibile l applicazione di tecniche di dependability improvement Inoltre, attraverso lo studio sistematico delle modalità di fallimento e la loro caratterizzazione statistica, ci si propone di individuare i failure pattern più 57

66 Capitolo 3 Failure Data Analysis di reti Bluetooth 58 comuni e le sequenze di operazioni in grado di scatenarli, con l obiettivo di suggerire strategie di programmazione per lo sviluppo di applicazioni dependable, ovvero strategie che eludano l utilizzo di operazioni critiche L approccio utilizzato per la valutazione della dependability di un sistema in fase operativa è generalmente un approccio measurement-based, in cui la raccolta e l analisi dei dati relativi ai fallimenti del sistema costituiscono la base per valutazioni generali sull affidabilità come ampiamente illustrato al Capitolo 2 La grossa difficoltà di una strategia del genere sta nel riuscire ad identificare what and how to measure 1 [RK00] ovvero nell individuare i parametri che realmente incidono sull affidabilità del sistema oggetto di studio In tal senso, a valle di uno studio delle caratteristiche architetturali di Bluetooth, si propone un interpretazione della dependability quale funzione di tre parametri: D = f(h, s, p) (31) ove: h=hardware technology s=system software p=bluetooth profile Uno studio teoricamente esaustivo della dependability in questo senso, presupporrebbe la sua valutazione per tutte le possibili combinazioni dei valori assunti dai parametri appena descritti: il presente lavoro di tesi avvia i lavori assegnando valori la cui probabilità di occorrenza è ragionevolmente più elevata, ed in particolare esaminando i Bluetooth Profiles più comunemente utilizzati ed i sistemi operativi di più largo consumo In Figura 31 è 1 cosa misurare e come misurarlo

67 Capitolo 3 Failure Data Analysis di reti Bluetooth 59 rappresentato lo stato dell arte: l intero cubo rappresenta lo spazio che si intende esplorare nell ambito dell attività di ricerca, i cubi colorati identificano le terne di valori finora prese in esame WIN LINUX SYM Profile P A N S P P O B E X D U N Software MOBILE PHONE HANDHELD PC Hardware & device class Figura 31: Studio della dependability di Bluetooth Rimanendo dunque fedeli ad un approccio meaurement-based, si propone una strategia di valutazione sul campo attraverso l utilizzo di un architettura software per la raccolta dei dati, la loro classificazione e la successiva analisi 32 La generazione e la raccolta dei dati Se un analisi esaustiva del grado di dependability -e dunque una valutazione il più possibile completa dei suoi attributi e parametri- è assicurata da un volume di dati che faccia riferimento ad un utilizzo continuativo dei servi-

68 Capitolo 3 Failure Data Analysis di reti Bluetooth 60 zi offerti, a conferire valenza realistica ai risultati ottenuti è l utilizzo di dati reali e dunque intrinsecamente a raffica Inoltre, al fine di comprendere a fondo le modalità di fallimento del sistema e le tecniche da adottare per scongiurarne le conseguenze, è necessario comprenderne gli effetti sull architettura hardware e software sottostante Sulla scorta di tali esigenze, l insieme dei dati necessari all analisi è un insieme eterogeneo che si è scelto di generare attingendo a tre diverse fonti di informazione: 1 System level data, ovvero dati raccolti dal meccanismo di logging del sistema operativo e legati ai protocolli coinvolti nel Bluetooth Stack (L2CAP, LMP, BNEP) Dati di questo tipo sono dunque registrati nel file di log, d ora in poi SystemLog, a partire dal quale sono poi generati due ulteriori logging file: InfoLog, ovvero un file contenente tutte i messaggi relativi agli eventi catturati dal logger di sistema; ErrorLog, ovvero un file contente i messaggi relativi esclusivamente ad situazioni di errore e warning La modalità di generazione dei suddetti file ed il formato delle informazioni risultano strettamente dipendenti dal sistema operativo Dati di questo tipo consentono di comprendere gli effetti dei fallimenti del canale sull architettura di supporto; 2 User level data, ovvero informazioni relative a fallimenti che utenti BT comunicano mediante l inserimento di una loro descrizione nel form disponibile all URL Data la poca sistematicità e la scarsa formalità delle informazioni così ottenute, i dati da esse deducibili sono utilizzati esclusivamente a conferma dei risultati ottenuti mediante il logging automatico;

69 Capitolo 3 Failure Data Analysis di reti Bluetooth 61 3 Emulation: la necessità di disporre di ingenti quantità di dati per conferire rilevanza statistica ai risultati dell analisi ha suggerito lo sviluppo di un software in grado di emulare il comportamento di un potenziale utente Bluetooth Dati appartenenti a questa classe, essendo generati in maniera continua, consentono di stimare determinati parametri di dependability (MTBF, MTTF) e risultano dunque estremamente significativi nell economia generale del lavoro di analisi Dettagli relativi al software e ai profili di traffico implementati sono rimandati al Paragrafo Architettura per la raccolta dati Per la raccolta dei dati di utente (user level data) e dei dati generati tramite emulazione del traffico, è stata utilizzata l architettura di Figura 32 BlueTest Client Bluetooth interface Bluetooth interface BlueTest Server Test log System log Test log System log LogAnalyzer network interface network interface LogAnalyzer CLIENT NODE SERVER NODE System log Bluetooth interface network interface Internet Internet User-log (web) Server LogAnalyzer network interface Collection log Server BLUETOOTH NODE DB Server (web) Log Client network interface DB USER WORKSTATION NODE Figura 32: Diagramma di alto livello del sistema di raccolta dati

70 Capitolo 3 Failure Data Analysis di reti Bluetooth 62 Un Bluetooth Node (BN) è un qualsiasi dispositivo dotato di un interfaccia Bluetooth e sul quale sia installato un Log Analyzer Quest ultimo è in grado di prelevare e filtrare i dati contenuti nel SystemLog per poi inviarli, dopo avere applicato opportuni algoritmi di coalescenza (cfr Paragrafo 33), al Log Server Node attraverso l interfaccia di rete (wireless o wired) disponibile sul dispositivo Uno User Workstation Node (UWN) è un qualsiasi dispositivo in grado di accedere ad Internet mediante un Web Browser Attraverso uno UWN un utente può interagire con il Log Server ed inserire una entry descrittiva di un qualsiasi fallimento Bluetooth contenente l ora in cui si è verificato il failure, una sua breve descrizione, l azione di recovery intrapresa ed eventuali altri commenti Un Client Node (CN) è un PC dotato di un interfaccia di rete Bluetooth, di un Log Analyzer e su cui sia installato il software di emulazione, BlueTest, attraverso il quale il CN riesce a comunicare con il server (SN, Server Node) Quest ultimo è un qualsiasi dispositivo Bluetooth in grado di accettare connessioni e fornire servizi Un CN registra i dati relativi ai fallimenti in un proprio file di log, TestLog Il Log Server Node (LSN) contiene tutti i dati raccolti e dispone di tre applicazioni server: 1 Web Server, per la raccolta dei dati di utente; 2 DB Server per l accesso al database; 3 Log Server per la raccolta dei dati provenienti da un Log Anayzer Maggiori dettagli tecnici circa lo schema del DB sono reperibili in [MC05]

71 Capitolo 3 Failure Data Analysis di reti Bluetooth 63 Protocollo Percentuale di utilizzo Web 425 Mail 26 P2P 34 Streaming 111 FTP 29 Others 69 Tabella 31: Percentuali di utilizzo dei protocolli in Internet 322 Emulazione del traffico: BlueTest ed i profili di carico L adozione di un approccio basato sull emulazione di un generico comportamento reale presuppone un approfondita conoscenza del problema al fine di poterne fornire una caratterizzazione in termini statistici o, qualora ciò non sia possibile, proporre delle euristiche in grado di riprodurlo in maniera adeguata BlueTest, il software riprogettato ed utilizzato nell ambito del presente lavoro di tesi, propone l emulazione dei profili di carico maggiormente rappresentativi per l utilizzo di una rete Bluetooth attingendo, ove possibile, alla letteratura più recente per quanto concerne le distribuzioni statistiche delle varie attività da riprodurre Focus del presente lavoro di tesi è lo studio della dependability di Bluetooth relativamente al profilo PAN ed ai profili basati su RFCOMM (cfr Figura 31) pertanto BlueTest è stato realizzato per la messa in esercizio di workload propriamente legati all utilizzo di Internet e alle attività di scambio file Inoltre si è scelto di implementare un profilo di più basso livello, LowLevelProfile per la valutazione dell affidabilità del canale in termini di integrità dei dati scambiati IP over Bluetooth workload Con particolare riferimento agli scenari IP over Bluetooth si è scelto di emulare i protocolli applicativi più comuni nella misura di cui alla Tabella 31

72 Capitolo 3 Failure Data Analysis di reti Bluetooth 64 A valle della scelta del particolare protocollo da utilizzare, BlueTest consente di stabilire i parametri caratteristici della sessione di trasferimento dati quali la dimensione dei pacchetti da inviare (L s ), la dimensione dei pacchetti ricevuti (L r ), il numero di pacchetti di cui si compone il trasferimento (N) ed il ritardo con cui l applicazione genera il traffico di sua competenza (D) La modalità di generazione dei parametri per ognuno dei protocolli considerati è descritta qui di seguito: WEB: Con riferimento alle attività di navigazione del WEB si è scelto di emulare una semplice sessione HTTP composta dal download di una pagina mediante l utilizzo di un browser Dal momento che una pagina è composta da più oggetti (testo, immagini, audio) si suppone che il numero di oggetti O sia uniformemente distribuito ed in particolare che: O U[1, 20] (32) Quanto alle dimensioni dei pacchetti: L r : Per le trasmissioni TCP sono generalmente utilizzati pacchetti di dimensione pari 572 o 1500 byte per i dati e pacchetti di 40 byte per l invio degli ACK Dal momento che si vuole emulare il download di una pagina occorre che L r sia scelto tra i primi due valori, in particolare [CF03]: P 572 = 08; P 1500 = 02 (33)

73 Capitolo 3 Failure Data Analysis di reti Bluetooth 65 L s : dal lato client, il flusso di pacchetti in uscita è costituito esclusivamente dagli ACK per cui si sceglie L s =40; N: Per il download di una pagina Web il numero di pacchetti da ricevere è pari a O N = n i (34) i=0 ove n i indica il numero di pacchetti per il download dell oggetto i simo e O il numero totale di oggetti di cui è composta la pagina E ragionevole pensare che n i sia dato dal rapporto tra la dimensione dell oggetto i simo, d i, e la dimensione dei pacchetti in ricezione, ovvero n i = d i /L r (35) E stato provato che la dimensione degli oggetti in download è modellabile attraverso una distribuzione di Pareto [MEC96], per cui si assume: d Pareto(11) (36) D: il ritardo nella generazione dei pacchetti può essere assunto ragionevolmente nullo contrariamente al ritardo che intercorre tra il download di due oggetti e che è noto in letteratura come active off time [MEC96] Esso si assume generalmente distribuito secondo una distribuzione di Weibull con parametro di forma k pari a 08 e parametro di scala θ pari a e 45

74 Capitolo 3 Failure Data Analysis di reti Bluetooth 66 P2P: una sessione di lavoro P2P consiste nel download o nell upload di un file Non c è motivo di pensare che una delle due attività sia più probabile dell altra pertanto la scelta tra le due avviene secondo una variabile bernoulliana con parametro p pari a 05 Dal momento che P2P utilizza il protocollo TCP possono ripetersi le considerazioni già viste per una sessione Web, in particolare: L r : Se si tratta di un attività di download esso è scelto come alla 33, viceversa L r =40; L s : dualmente a quanto fatto per L r, L s è scelto come alla 33 -se si tratta di un attività di upload- mentre L s =40 se si tratta di un download; N: sia in caso di download sia di upload, la dimensione dei file d può essere generata secondo una distribuzione di Pareto: d 10 Pareto(11) (37) ove il coefficiente moltiplicativo è stato introdotto in quanto i file scambiati attraverso P2P sono ragionevolmente più grossi del normale (audio,video) N può essere calcolato come alla 34; D: il ritardo nella generazione dei pacchetti può essere assunto ragionevolmente nullo MAIL: l invio di una mail è sostanzialmente riconducibile ad una sessione P2P se si intende l inoltro di un messaggio come un attività di upload e la sua ricezione come un download I parametri risultano pertanto assimilabili a quelli visti per il P2P eccetto

75 Capitolo 3 Failure Data Analysis di reti Bluetooth 67 d che, viste le ridotte dimensioni di un messaggio di posta, si assume così distribuito: d Pareto(11) (38) FTP: è legittimo supporre che su un dispositivo mobile non siano installate applicazioni di FTP server pertanto è possibile assimilare una sessione FTP ad una sessione di download P2P Sulla scorta di questa assunzione si ha: L r : è scelto come alla 33; L s : poiché si tratta esclusivamente di TCP ACKS, L s =40; N: sia in caso di download sia di upload, la dimensione dei file scambiati d può essere generata secondo una distribuzione di Pareto: d 10 Pareto(11) (39) ove il coefficiente moltiplicativo è stato introdotto in quanto i file scambiati attraverso FTP sono ragionevolmente più grossi del normale (audio,video) N può essere calcolato come alla 34; D: il ritardo nella generazione dei pacchetti può essere assunto ragionevolmente nullo STREAMING: una sessione di streaming è modellata come una sessione di download di pacchetti UDP I parametri sono generati come segue: L r : le applicazioni multimediali generano pacchetti mediamente lunghi 875 byte [CF03] pertanto L r =875;

76 Capitolo 3 Failure Data Analysis di reti Bluetooth 68 L s : si assume nullo in quanto il client non spedisce alcun pacchetto eccetto quelli relativi alla negoziazione del canale; N: sia in caso di download sia di upload, la dimensione dei file scambiati d può essere generata secondo una distribuzione di Pareto: d 10 Pareto(11) (310) N può essere calcolato come alla 34 ed interpretato come N = d/l r in caso di download, N = d/l s in caso di upload; D: il ritardo nella generazione dei pacchetti può essere assunto ragionevolmente nullo Il tempo che intercorre tra la fine dell attività di un attività e l inizio della successiva è noto in letteratura, con riferimento alle sessioni Web, come passive-off-time [MEC96] e si assume distribuito secondo una distribuzione di Pareto: T w Pareto(15) (311) Verosimilmente si può assumere che anche il tempo di attesa tra due sessioni FTP, P2P, STREAMING e MAIL sia distribuito come alla 311 File exchange workload Per quel che concerne le attività di scambio file tra due dispositivi Bluetooth enabled, dal momento che esse riguardano prevalentemente

77 Capitolo 3 Failure Data Analysis di reti Bluetooth 69 il trasferimento di ridotte quantità di dati (immagini, Business Card, clip audio ) si è scelto di modellare la dimensione dei file come segue: d Pareto(11) (312) Il trasferimento di file su canali Bluetooth avviene utilizzando un protocollo di trasporto seriale: per la generazione dei parametri caratteristici di una sessione di scambio si fa dunque riferimento ai valori caratteristici di RFCOMM In particolare, dal momento che RFCOMM è in grado di segmentare i pacchetti che eccedono la dimensione della massima MTU pertanto si può assumere la dimensione del file d sia pari a ((N 1) MTU MAX + R) ove R indica la quantità di byte in eccesso ed è minore di MTU MAX N: alla luce di quanto appena esposto, il numero di pacchetti può essere interpretato N = d/mtu MAX sia nel caso di invio sia di ricezione del file; L r : in caso di download si assume L r [i] = RFCOMM MAX MTU i < N 1; L r [N] = R (313) In caso di upload L r = 0; L s : in caso di upload si assume L s [i] = RFCOMM MAX MTU i < N 1; L s [N] = R (314) In caso di download L s = 0

78 Capitolo 3 Failure Data Analysis di reti Bluetooth 70 D: il ritardo nella generazione dei pacchetti può essere assunto verosimilmente nullo LowLevelTest workload Accanto ai profili di carico di natura applicativa appena illustrati, BlueTest implementa un ulteriore profilo di più basso livello, LowLevel- Test, volto a valutare l affidabilità del particolare protocollo di trasporto utilizzato: attraverso il trasferimento di pacchetti grezzi sul canale Bluetooth instaurato tra due dispositivi della rete si vuole stimare la probabilità di perdita e di compromissione del contenuto informativo degli stessi Il profilo è caratterizzato dallo scambio di pacchetti di dimensione fissata pari alla massima consentita dal protocollo Entrambi i dispositivi coinvolti nella comunicazione effettuano operazioni di controllo dell errore al fine di valutare l integrità del pacchetto ricevuto: ciò è reso possibile dalla struttura fissa e nota dei pacchetti scambiati che, esclusivamente per semplicità di implementazione, contengono una sequenza di caratteri tutti uguali La responsabilità di valutare la natura dell errore è interamente assegnata al client: il fallimento del controllo di integrità lato server - comunicato tramite l invio di un pacchetto speciale- segnala evidentemente un errore in trasmissione, viceversa un fallimento del controllo lato client rivela un errore in ricezione Sia lato client sia lato server viene esaminato l intero contenuto del pacchetto per valutare la natura e l entità dell errore Sintetizzando, è possibile schematizzare il comportamento di BlueTest e la gestione dei workload profiles mediante un vettore di parametri caratteristici (cfr Figura 33): S: Scan flag, ovvero un flag che indica se sarà effettuata o meno

79 Capitolo 3 Failure Data Analysis di reti Bluetooth 71 l operazione di scanning; B: Baseband Packet type, ovvero il particolare tipo di pacchetto Bluetooth da utilizzare per la trasmissione 2 ; WL: WorkLoad profile, ovvero la particolare attività da riprodurre (WEB, FTP); L r, L s, N, D: come definiti al Paragrafo 322 S B WL Lr Ls N D Figura 33: Vettore dei parametri caratteristici di una sessione 33 Filtraggio e coalescenza dei dati: il LogAnalyzer In un processo di valutazione measurement-based la fase di raccolta dei dati è generalmente seguita da una serie di operazioni di manipolazione degli stessi per far fronte a due situazioni tipiche che renderebbero altrimenti complesso il lavoro di analisi: 1 Volume dei dati: le informazioni raccolte dagli appositi logger daemon di ogni SO sono generalmente ridondanti e non tutte significative ai fini dell analisi che si intende condurre La riduzione della mole di informazioni da gestire, senza alterarne il contenuto informativo, agevola i processi di interrogazione dei dati oltre che eventuali operazioni di invio ad una central repository remota 2 B può assumere uno tra i seguenti valori: DH1, DM1, DH3, DM3, DH5, DM5

80 Capitolo 3 Failure Data Analysis di reti Bluetooth 72 2 Formato dei dati: il formato con cui le informazioni sono registrate sui log file varia non soltanto al variare del SO ma anche della sorgente da cui esse provengono e dalla loro tipologia (informazioni di errore, warning, alert) pertanto tipicamente si cerca di renderle conformi ad un formato predefinito Nell architettura di Figura 32 la responsabilità di dette manipolazioni è demandata al LogAnalyzer il cui diagramma degli stati di alto livello è riportato in Figura 34 Figura 34: Diagramma di alto livello del LogAnalyzer L applicazione è progettata per processare le tre differenti tipologie di log file generate dai nodi dell architettura di Figura 32 -ossia ErrorLog, InfoLog e TestLog- e lavora in quattro fasi che si ripetono ciclicamente: estrazione dei dati dal file di log (1), filtraggio delle informazioni indesiderate (2), applicazione degli algoritmi di coalescenza (3), invio al Collection Log Server 1 Allo scattare di un timer, tipicamente ogni ora, il LogAnalyzer esce dallo stato Asleep (cfr Figura 34) ed effettua una copia di lavoro dei file di log attraverso una particolare funzionalità di logrotate; 2 Il filtraggio dei dati avviene facendo ricorso a due liste in cui sono stati preventivamente inseriti i tag relativi agli eventi interessanti e dunque da salvare -whitelist- ed i tag identificativi di eventi non interessanti e dunque da filtrare, blacklist La manipolazione dei dati contenuti

81 Capitolo 3 Failure Data Analysis di reti Bluetooth 73 nelle liste avviene modificando un file di configurazione in modo tale da consentire all applicazione di adattarsi alla particolare strategia di filtering senza la necessità di apportare modifiche strutturali al codice 3 Il LogAnalyzer mette in opera sia strategie di coalescenza temporale sia di coalescenza basata sul contenuto La prima, come già illustrato al Paragrafo 241, è volta a ripulire i file di log da entry relative al medesimo evento e registrate a breve distanza; la strategia di compattazione delle entry implementata dal LogAnalyzer è la strategia del tupling di cui ancora al 241 La coalescenza basata sul contenuto, invece, è volta alla riduzione del volume dei dati e punta a raggruppare più entry relative al medesimo evento in un unica entry rappresentativa dell evento stesso e contenente esclusivamente le informazioni necessarie In particolare il LogAnalyzer riduce le informazioni relative al boot ed allo shutdown di un host mediante l individuazione di un pattern di start/stop 4 Una volta completate le operazioni di filtraggio e coalescenza, il LogAnalyzer invia i dati al Collection Log Server al quale è demandata la responsabilità di trasferirli sul database per le successive elaborazioni 34 Stato dell arte La ricerca nel campo della failure data analysis ha finora proposto numerosi approcci e metodologie che differiscono a seconda del particolare sistema oggetto di studio RIyer at al in [RK00] offrono una trattazione sistematica delle metodologie possibili focalizzando l attenzione sull analisi sul campo e su un approccio measurement-based, mentre in [AT96] e [RKSZ04] sono riportati casi di studio applicati a reti di workstation e a large scale

82 Capitolo 3 Failure Data Analysis di reti Bluetooth 74 heterogeneous server environments Un attenzione particolare è rivolta allo studio dell affidabilità di reti wireless, tra cui Wi-Fi [DCT03], e allo studio dei failure modes dei dispositivi AP [MEC96] Ancora, in [SCS04] è riportato un interessante studio sulla dependability delle reti ad hoc mentre Bondavalli et al in [SP] propongono un modello per la valutazione della depenability della tecnologia gprs Un interessante sistema di raccolta ed analisi dei dati per un sistema wireless è proposto in [SMMM02] Con particolare riferimento a Bluetooth, un attività di raccolta di dati relativi ai fallimenti è stata condotta in [DDDD04] Attraverso l applicazione di test-case differenti applicati a coppie di dispositivi eterogenei per tipologia e casa produttrice vengono raccolti dati relativi ad errori rilevati durante le connessioni al fine di testare l interoperabilità in un ottica user-perceived I casi di test fanno riferimento a tutti i profili applicativi contemplati da Bluetooth, incluso il profilo headset per il trasferimento di voce su canali SCO Sebbene gli obiettivi del lavoro appena citato divergano in partenza dagli obiettivi del presente lavoro di tesi può essere interessante confrontare i risultati ottenuti relativamente ai tipi di fallimento e alla loro frequenza di occorrenza L approccio adottato in [DDDD04], non essendo rigoroso, fornisce un idea globale dei failure modes di Bluetooth e delle percentuali di fallimento senza però fornire stime quantitative per i parametri di dependability Inoltre, le azioni di ripristino proposte in [DDDD04] (ritrasmissione del file, verifica dello stato di carica della batteria) differiscono dalle strategie implementate in BlueTest essendo esclusivamente azioni perseguibili da utenti finali e dunque di alto livello Ulteriore punto di divergenza sta nella diversa fornitura dei servizi che in [DDDD04] è evidentemente non

83 Capitolo 3 Failure Data Analysis di reti Bluetooth 75 continuativa e dunque non adatta a fornire indicazioni circa la reliability del sistema e dei parametri ad essa legati Se da un lato in [DDDD04] viene effettuata una vasta gamma di test su un elevato numero di dispositivi (circa 30) fornendo una notevole eterogeneità ai risultati, la rilevanza statistica degli stessi è limitata dalla quantità di dati ancora esigua Ad ogni modo, nonostante le profonde differenze in termini di approccio e metodologia, un confronto sui risultati finali -effettuato a parità di dispositivi e profilo applicativo- potrebbe rilevare interessanti legami tra i modi di fallimento percepiti a livello utente in condizioni reali e quelli rilevati a livello sistema sui dati raccolti dai workload in esercizio

84 Capitolo 4 La dependability del profilo PAN L esigenza di una mobilità sempre più spinta e la necessità di disporre dell accesso al Web da ogni dove ha incrementato l utilizzo di Bluetooth quale tecnologia per il last meter access rendendo il Personal Area Networking scenario estremamente diffuso Attraverso un dispositivo bridge, esso consente a dispositivi Bluetooth enabled l accesso alla rete Internet oltre alla possibilità di costituire reti self-contained per la condivisione di risorse Il profilo Bluetooth che formalizza il paradigma del Personal Area Networking è il profilo PAN di cui nel presente capitolo si riporta uno studio sperimentale dell affidabilità Alle prime sezioni in cui è fornita una descrizione del profilo e degli strumenti software utilizzati per lo sviluppo di applicazioni che ne facciano uso, segue una sezione dedicata all architettura del testbed realizzato per la raccolta e la generazione di dati emulati La parte centrale focalizza l attenzione sulla progettazione e l implementazione di un client con sistema operativo Windows integrato nell architettura preesistente In chiusura si illustrano i risultati sperimentali dell analisi congiuntamente a considerazioni circa i tipi di fallimento riscontrati, la loro distribuzione e l efficacia delle azioni di ripristino 41 Il profilo PAN Un profilo Bluetooth è l insieme delle regole che disciplinano l utilizzo del Bluetooth stack in ogni dispositivo, in particolare definisce: quali caratteristiche sono richieste allo stack per la fruizione e/o la pubblicazione del servizio cui il profilo stesso si riferisce; il modo in cui uno sviluppatore deve utilizzare le apposite API per interfacciarsi al protocollo Bluetooth sottostante; 76

85 Capitolo 4 La dependability del profilo PAN 77 Figura 41: BNEP: Incapsulamento di un frame Ethernet in un pacchetto L2CAP le regole comportamentali che un generico utilizzatore è tenuto a seguire per abilitare le funzionalità a livello utente Il profilo PAN (Personal Area Networking Profile) formalizza le regole grazie a cui due o più dispositivi Bluetooth possono connettersi a formare una rete ad hoc e che stabiliscono come il medesimo meccanismo possa essere utilizzato per accedere alla rete Internet attraverso un punto di accesso (NAP, Network Access Point) definendo pertanto anche i modi per il trasporto di traffico IP su connessioni Bluetooth Il protocollo grazie al quale avviene la conversione del traffico IP in traffico Bluetooth è il protocollo BNEP (Bluetooth Network Encapsulation Protocol) che incapsula frame Ethernet in pacchetti L2CAP (l analogo Bluetooth del livello MAC, Medium Access Control), come descritto in Figura 41 La Figura 42 illustra un dettaglio dello stack Bluetooth relativo a BNEP; maggiori dettagli sul formato dei pacchetti e sulle modalità di incapsulamento sono reperibili in [SIG01a] IP BNEP L2CAP BT Baseband BT RF Figura 42: Dettaglio dello stack Bluetooth

86 Capitolo 4 La dependability del profilo PAN 78 Per il profilo PAN sono definiti due scenari di utilizzo ognuno dei quali caratterizzato da una specifica topologia e da specifici requisiti di rete: 1 Network Access Point (NAP): un Network Access Point è un dispositivo che funge da brigde tra la rete IP ed una piconet Bluetooth consentendo ai dispositivi che ne fanno parte di accedere alla rete e a tutte le sue risorse; la topologia caratteristica di uno scenario NAP è quella di Figura 43 ÄÅÆÇÈÉÊ ÄÅÆÇÈÉÊ ÄÅÆÇÈÉÊ ÀÁÂÃÀÂÁ NAP ÄÅÆÇÈÉÊ Figura 43: PAN:scenario di utilizzo NAP 2 Group Ad-Hoc Networks (GN): una rete ad hoc è una rete in cui più dispositivi, coordinati da un master, si connettono tra loro a formare una rete self-contained ovvero senza l utilizzo di hardware o infrastrutture di rete aggiuntive La topologia di una rete ad hoc è quella di Figura 44 Un PAN User (PANU) è un dispositivo che usufruisce del servizio NAP e/o del servizio GN e dunque riveste il ruolo di client in entrambi gli scenari Quanto alle dipendenze, il profilo PAN poggia esclusivamente sul profilo GAP (Generic Access Profile); ulteriori dettagli sul profilo PAN e sulla modalità di instaurazione delle connessioni sono disponibili in [SIG01b]

87 Capitolo 4 La dependability del profilo PAN 79 ËÌÍÎÏ ËÌÍÎÏ ÐÑÒÓÔÕ ËÌÍÎÏ ËÌÍÎÏ ËÌÍÎÏ Figura 44: PAN: Scenario Group Ad Hoc Networking 42 Il testbed L architettura del testbed utilizzato per la raccolta dei dati emulati (cfr Capitolo 3), è illustrata in Figura 45 e riproduce una piconet Bluetooth costituita da sette dispositivi nel raggio di dieci metri Linux Client Miseno Linux Client PDA Ipaq Linux Server Linux Client PDA Zaurus Linux Client Verde Linux Client Capatamarano Windows Client Win Figura 45: Architettura del testbed In un ottica coerente con l interpretazione della dependability di Blue-

88 Capitolo 4 La dependability del profilo PAN 80 tooth quale funzione di tre parametri cfr Paragrafo 31), il testbed è strutturato in maniera eterogenea con riferimento sia alle caratteristiche hardware sia software dei nodi come è riportato in Tabella 41 Host SO Distribuzione Kernel CPU RAM Giallo Linux Mandrake mdk P4 160GHz 128Mb Verde Linux Mandrake mdk P3 350Mhz 256Mb Miseno Linux Debian Celeron 700Mhz 128Mb Capatamarano Linux Fedora P4 170GHz 512Mb Win Win XP SP2 P4 180Ghz 512Mb Ipaq H3870 Linux Familiar rmk6-pxa1-hh37 StrongARM 206 MHz 64 Mb Zaurus SL-5600 Linux Open Zaurus rmk7-pxa3-embedix XScale 400Mhz 32Mb Tabella 41: Testbed, caratteristiche tecniche L eterogeneità dal punto di vista della tecnologia hardware è stata caratteristica del testbed sin dai primi esperimenti, per quanto concerne il software, invece, esso è stato concepito per operare in ambiente Linux ed ha subito -nell ambito del presente lavoro di tesi- l integrazione di un nodo con sistema operativo Windows XP La particolare attenzione ai sistemi operativi installati sui diversi host è giustificata dal fatto che il Bluetooth Stack è generalmente un componente di livello kernel e dunque a stretto contatto con i meccanismi di gestione delle interfacce messi in opera dal software di base Alla luce di questa considerazione è ragionevole supporre che l impatto di fallimenti Bluetooth sul sistema possa variare a seconda del sistema operativo e che, viceversa, il sistema operativo possa in qualche modo incidere sulle modalità di fallimento: l analisi di natura comparativa condotta da tale lavoro di tesi è volta ad avallare quest ipotesi Ad oggi gran parte dei sistemi operativi di largo consumo dispone di un supporto a Bluetooth partendo dal consolidato BlueZ in ambiente Linux, passando per i moduli Bluetooth di Symbian e Windows CE, fino al giovanissimo supporto di Windows XP Le sezioni che seguono descrivono i

89 Capitolo 4 La dependability del profilo PAN 81 supporti offerti dai so facenti parte del testbed concentrando l attenzione sulle problematiche legate al loro utilizzo ed in particolare al profilo PAN 43 Linux e Bluetooth: lo stack BlueZ BlueZ è lo stack Bluetooth ufficiale in ambiente Linux sviluppato inizialmente dalla Qualcomm Incorporated e ora distribuito in maniera open-source sotto licenza GNU GPL (General Public License) Ufficialmente parte del kernel di Linux a partire dalla versione 246, il kernel di BlueZ consiste di una serie di moduli tra cui: Bluetooth kernel subsystem core; livello kernel di L2CAP e SCO audio; implementazione del livello kernel di RFCOMM e BNEP; HCI UART, USB, PCMCIA e driver di device virtuali; librerie e demoni per General Bluetooth ed SDP; utilità di test e configurazione; strumenti di monitoring ed analisi (quale ad esempio hcidump per il monitoring delle connessioni a livello HCI) Diverse sono le caratteristiche che hanno consolidato il successo di BlueZ rendendolo ad oggi lo stack più utilizzato, tra le altre: l implementazione completamente modulare; il supporto per diversi dispositivi Bluetooth; l utilizzo di un interfaccia socket standard per tutti i livelli Bluetooth;

90 Capitolo 4 La dependability del profilo PAN 82 il supporto per la sicurezza di servizi e dispositivi; la compatibilità con le più diffuse piattaforme hardware (Intel e AMD x86, AMD64 (x86-64), SUN SPARC 32/64bit, PowerPC 32/64bit, Intel StrongARM and XScale, Motorola DragonBall ) 431 BlueZ e il profilo PAN La realizzazione di applicazioni che utilizzino il profilo PAN è resa possibile dal supporto che BlueZ offre per BNEP ed L2CAP, come è semplice dedurre dal dettaglio di Figura 42 La struttura completamente modulare di BlueZ richiede il precaricamento di moduli relativi ai livelli sottostanti prima di poter stabilire una connessione PAN: deputato ad abilitare il profilo e a stabilire le connessioni è un particolare demone, pand, che va invocato previo il caricamento dei moduli relativi ad HCI (Host controller Interface), L2CAP e BNEP Dettagli relativi all installazione di BlueZ, al caricamento dei moduli e all utilizzo dei vari profili sono rimandati all Appendice A 44 Windows XP e Bluetooth Il supporto Bluetooth è disponibile nei sistemi Windows XP a partire dalla release SP1 (Service Pack 1), nei sistemi XP Embedded a partire dal SP2 ed in tutti i sistemi Windows CE Prerequisito al corretto funzionamento delle applicazioni Bluetooth in ambiente XP è l installazione di un apposito package, Windows XP Embedded-based run-time, per la risoluzione delle opportune dipendenze Il supporto Bluetooth di Microsoft fornisce servizi di base molto simili a quelli già proposti per altri protocolli di trasporto, tra cui TCP, e -analogamente a quanto accade per numerosi altri protocolli di networking- l interfaccia fornita per l implementazione delle connessioni e dei

91 Capitolo 4 La dependability del profilo PAN 83 file transfer Bluetooth è di tipo socket-based Più precisamente, Microsoft fornisce due diversi approcci per la programmazione Bluetooth: 1 Managing devices directly by using nonsocket Bluetooth interfaces, ovvero la gestione a basso livello dei dispositivi senza l utilizzo di un interfaccia socket; 2 Using the Windows Sockets interface, ovvero la gestione dei dispositivi e delle connessioni ad un livello più elevato qual è il livello socket Il primo approccio prevede la manipolazione e l accesso a dispositivi Bluetooth mediante l utilizzo di numerose funzioni e strutture dati spesso legate tra loro da fitte relazioni di dipendenza che ne rendono poco intuitivo l utilizzo Il secondo approccio, invece, prevede l utilizzo dell interfaccia socket standard opportunamente estesa per rendere possibile l implementazione di operazioni prettamente legate a Bluetooth quali la scoperta dei dispositivi e/o dei servizi disponibili Con particolare riferimento ai sistemi XP, sebbene le API fornite nell ambito del Microsoft Platform SDK consentano l implementazione di tutte le operazioni Bluetooth, l interfaccia socket-based messa a disposizione da Microsoft consente esclusivamente l accesso ai protocolli basati su RFCOMM e non ai livelli inferiori inibendo pertanto lo sviluppo di applicazioni che utilizzino protocolli di comunicazione diversi da quello seriale Una siffatta struttura dello stack (cfr Figura 46) e la conseguente carenza, in termini di API, di strumenti per l accesso ai livelli L2CAP e BNEP rendono impossibile lo sviluppo di applicazioni basate sul profilo PAN A valle di tale conclusione si è scelto di utilizzare per l implementazione di un client BlueTest (cfr Capitolo 3) in ambiente Windows uno stack commerciale che consentisse la creazione e la gestione di connessioni PAN

92 Capitolo 4 La dependability del profilo PAN 84 ed in particolare, data la grande diffusione di cui gode, si è optato per lo stack Windows compliant BCM1000-BTW sviluppato da Broadcom Figura 46: Microsoft Bluetooth Stack Ulteriori dettagli sull installazione del supporto Microsoft, sulle funzioni disponibili e semplici esempi d uso sono rimandati all Appendice A 441 Lo stack Broadcom Bluetooth for Windows (BCM1000-BTW) è la soluzione software di Broadcom progettata per aggiungere funzionalità complete di supporto Bluetooth ai sistemi operativi Windows ed è completamente conforme alla versione 12 delle specifiche ufficiali Bluetooth [SIG03] Il pacchetto include oltre a strumenti di supporto e test anche un approfondita documentazione delle API In Figura 47 è rappresentata la struttura dello stack software

93 Capitolo 4 La dependability del profilo PAN 85 BCM1000-BTW che consente l accesso diretto a numerosi livelli e profili dello stack Bluetooth (L2CAP, RFCOMM, OPP, FTP, SDP, SPP, LAP, OBEX, DUN) e, sviluppato per la programmazione C++, consiste di: una libreria statica (WidcommSdkLiblib); header file C++ (BtIfDefinitionsh, BtIfClassesh, BtIfObexHeaderh, comerrorh); codici sorgenti per applicazioni di esempio Figura 47: Diagramma a blocchi del BTW Development Kit Le API fornite dal BCM1000-BTW DK (Development Kit) sono strutturate in classi e fanno ricorso al meccanismo delle interfacce (classi astratte in C++): una qualsiasi applicazione che ne faccia uso deve pertanto implementare classi che definiscano i metodi pubblicati nelle interfacce stesse al fine di specializzare il comportamento in risposta a particolari eventi Bluetooth quali, tra gli altri, la risposta di un dispositivo ad una richiesta di connessione o il completamento della procedura di inquiry

94 Capitolo 4 La dependability del profilo PAN 86 In Tabella 48 sono riportate le classi offerte dal DK accanto ad una breve descrizione delle loro funzionalità Figura 48: Classi offerte dal BCM1000-BTW DK 45 BlueTest e il profilo PAN I dati necessari all analisi della dependability con riferimento al profilo PAN derivano dall opportuna specializzazione delle possibili sorgenti di informazione di cui si è discusso in termini generali al Paragrafo 32 Per ciò che concerne il livello sistema i dati legati ai fallimenti del profilo PAN possono essere individuati selezionando dal file di log le righe in cui la sorgente di errore sia una determinata categoria di applicazioni Bluetooth; analogamente, con riferimento agli user level data, è possibile isolare le entry di interesse selezionando esclusivamente i fallimenti registrati durante la navigazione in rete o durante una sessione di group networking, a patto che la descrizione fornita dagli utenti sia sufficientemente dettagliata La generazione di dati emulati, invece, richiede l utilizzo del software BlueTest di cui al Paragrafo 322 in una configurazione specifica, da ora BlueTestPAN

95 Capitolo 4 La dependability del profilo PAN 87 Probabilità Valore P SDP P( scan sdp) 06 P SCAN P( sdp scan) 015 P BOTH P(sdp scan) 015 P NONE P( sdp scan) 01 Tabella 42: Probabilità di occorrenza per SCAN ed SDP SEARCH Un diagramma degli stati ad alto livello, relativo ad un client Blue- TestPAN è riportato in Figura 49 SCANNING event scan/ scanning event scan/ SDP search CONNECTION do/ L2CAP connect do/ PAN connect USE entry/ switch role do/ send/receive DISCONNECTION do/ disconnect WAIT exit/ WL = 0 Figura 49: BlueTest: flusso di esecuzione in assenza di errori Ogni CN (Client Node)parte dallo stato SCANNING per ritornarvi periodicamente dopo un periodo di attesa (stato WAIT) La permanenza di un CN in stato SCANNING corrisponde al momento in cui esso è impegnato in operazioni di scanning dei dispositivi vicini (inquiry) e/o di scoperta dei servizi (sdp search) Verosimilmente, infatti, ogni utente intenzionato ad utilizzare Bluetooth per accedere alla rete Internet o per uno scambio di file con un altro dispositivo ha necessità di sondare la presenza di altri dispositivi nel suo raggio d azione e/o la possibilità di usufruire di un certo servizio La frequenza di occorrenza di dette operazioni (inquiry e/o sdp search) è stata stabilita grazie ad euristiche derivanti da osservazioni sull usuale utilizzo di Bluetooth ed è riportata in Tabella 42 E legittimo assumere che l evento più probabile sia da associare alla ricerca di un servizio in quanto nella maggior parte dei casi un device intenzionato ad usufruire di un certo servizio è tenuto ad accertarsi della presenza

96 Capitolo 4 La dependability del profilo PAN 88 di un dispositivo in grado di offrirlo (provider) Il minor peso assegnato all evento congiunto di scan ed sdp search è da giustificarsi pensando ai frequenti fenomeni di caching grazie ai quali un dispositivo può evitare di effettuare l inquiry prima di ogni tentativo di connessione: effettivamente l operazione di scanning è strettamente necessaria soltanto se il dispositivo fa ingresso in una zona inesplorata Può inoltre accadere che un dispositivo riesca a stabilire una connessione senza necessariamente effettuare né scan ed né sdp search: ciò si verifica nel caso di tentativi di connessione ravvicinati allo stesso dispositivo per richiedere il medesimo servizio A valle della fase di scoperta e della successiva fase di pairing, corrispondente allo stato CONNECTION di Figura 49 ed in cui viene casualmente selezionato il tipo di pacchetto Bluetooth in accordo ad una distribuzione binomiale, un CN perviene allo stato USE in cui viene emulata l effettiva attività svolta dal client secondo le modalità di generazione del traffico descritte al Paragrafo 322 e che è illustrata in dettaglio nel diagramma di Figura 410 In particolare, con riferimento al profilo LowLevelTest la dimensione dei pacchetti è assunta pari alla massima MTU imposta da BNEP (1691byte) ed il numero di pacchetti per ogni sessione è scelto pari a RECOVERY Lr,Ls,N,D Exception P(scan e/o sdp), S Exception Exception Exception USE Exception SCANNING CONNECTION Established Protocol Generated Parameters WAIT DISCONNECTION P(Web P2P Mail Streaming Ftp) Figura 410: Diagramma degli stati dettagliato di BlueTestPAN

97 Capitolo 4 La dependability del profilo PAN 89 Al termine della sessione ogni CN si porta nello stato DISCONNECTION in cui si provvede a chiudere la connessione ed a liberare le risorse utilizzate per poi giungere nello stato di WAIT in cui permane per un tempo pari al passive-off-time 451 La gestione degli errori e le azioni di recovery Per la gestione degli errori durante il normale ciclo di esecuzione del programma, BlueTestPAN implementa diverse azioni di recovery per il ripristino del corretto funzionamento Queste ultime, oltre ad evitare l arresto del test in seguito ad errori recuperabili, consentono la sperimentazione sul campo dell efficacia di azioni di ripristino on-line In seguito al manifestarsi di un errore, il CN entra nello stato RECOVERY in cui si cerca di ripristinarne lo stato : una variabile, WL (warning level), incrementata in seguito ad ogni interruzione anomala del programma, è indicativa della particolare azione da avviare e conseguentemente della gravità del guasto Al crescere del valore di WL, che può oscillare nell intervallo degli interi [1, 4], cresce la severità dell azione da intraprendere (cfr Tabella 43); dal successo di una determinata azione di recovery è possibile dedurre l entità responsabile del fallimento In Figura 411 è illustrato il diagramma degli stati di BlueTestPAN alla luce di quanto appena esposto WL Recovery 1 Distruzione/creazione del canale Bluetooth 2 Riavvio del Bluetooth Stack 3 Riavvio dell applicazione BlueTest 4 Reboot della macchina Tabella 43: Azioni di recovery

98 Capitolo 4 La dependability del profilo PAN 90 RECOVERY Lr,Ls,N,D Exception P(scan e/o sdp), S Exception Exception Exception USE Exception SCANNING CONNECTION Established Protocol Generated Parameters WAIT DISCONNECTION P(Web P2P Mail Streaming Ftp) Figura 411: BlueTest: flusso di esecuzione in presenza di errori 46 BlueTestPAN in ambiente Linux La realizzazione di un client BlueTestPAN per sistemi operativi Linux ha interessato la prima fase del lavoro di ricerca di più ampio raggio in cui il presente lavoro di tesi si inserisce ma le attività di testing e miglioramento continuano incessanti tuttora Gli stati di un client BlueTest descritti nel Paragrafo precedente (cfrfigura 411) identificano le parti in cui è possibile suddividere la struttura del programma: SCANNING La permanenza di un CN nello stato Scanning modella il tempo necessario al programma per calcolare la probabilità degli eventi di scan e/o sdp search (cfrtabella 42) utilizzando la libreria newrand02 per la generazione delle variabili casuali CONNECTION e DISCONNECTION L infrastruttura di comunicazione Bluetooth tra un CN ed un SN è stata realizzata mediante l implementazione di classi wrapper per i meccanismi messi a disposizione da BlueZ Con particolare riferimento all applicazione client sono state realizzate le classi Connection,

99 Capitolo 4 La dependability del profilo PAN 91 Connection +PrepareHandover() : void +Connect() : void +CompleteConnection() : void +Disconnect() : void +Search() : int +GetRssi() : int +getapaddress() : string +isconnected() : bool BlueConnection -struct hci_conn_info_req*cr -int sk -bdaddr_t bdaddr clientaddress -string address -int devicedescriptor -bool connected -bool panconn -bool bnepinitialized -_l2 l2a +BlueConnection() +SDPSearch() : void +SwitchRole() : void Figura 412: Diagramma delle classi Connection e BlueConnection astratta, e la classe da essa derivata BlueConnection il cui diagramma è riportato in Figura 412 I metodi Connect() e Disconnect() fanno riferimento ad una connessione L2CAP mentre il metodo CompleteConnection() provvede alla creazione di una connessione PAN Le operazioni di scan ed sdp search sono realizzate rispettivamente dai metodi Search() ed SDPSearch() USE A valle della creazione della connessione PAN il dispositivo client passa ad utilizzare il canale per l utilizzo della rete Internet generando dunque traffico IP per il quale si è scelto di utilizzare il protocollo di trasporto UDP in quanto la sua natura connection-less permette di evidenziare errori che sarebbero altrimenti mascherati senza gorgogliare a livello applicativo La gestione delle socket a questo livello è stata resa possibile dalla realizzazione della classe SockDatagram che astrae i metodi propri del interfaccia socket-based Per ciò che concerne invece la messa in esercizio dei profili di carico di cui al Paragrafo 322 è stata realizzata la gerarchia di classi di Figura 413

100 Capitolo 4 La dependability del profilo PAN 92 WorkloadProfile #Lr : uint #Ls : uint #filedimension : uint #packetnumber : uint #sockdatagram*sck #remoteaddress : string #serverport : uint #conntimeout : uint #Logger*loggerr #numpacket : uint +WorkloadProfile() +virtual~workloadprofile() +channelnegotiation() : void +virtual calculateconnparameters() : void +virtual dojob() : void +GetLr() : uint +GetLs() : uint +GetNUmPackets() : uint * * * * * FTPWorkloadProfile -download : bool +FTPWorkloadProfile() +virtual~ftpworkloadprofile() : void +calculateonnparameters() : void +dojob() : void * MAILWorkloadProfile -objects : int -SleepTime : ulong -sendmail : bool +MAILWorkloadProfile() +virtual~mailworkloadprofile() : void +calculateonnparameters() : void +dojob() : void * WEBWorkloadProfile -objects : int -SleepTime : ulong +WEBWorkloadProfile() +virtual~webworkloadprofile() : void +calculateonnparameters() : void +dojob() : void P2PWorkloadProfile -download : bool +P2PWorkloadProfile() +virtual~p2pworkloadprofile() : void +calculateonnparameters() : void +dojob() : void StreamWorkloadProfile +StreamWorkloadProfile() +virtual~streamworkloadprofile() : void +calculateonnparameters() : void +dojob() : void Figura 413: Gerarchia di classi Workload RECOVERY Un dispositivo si porta nello stato RECOVERY in seguito ad un eccezione lanciata da una delle funzioni invocate durante la normale esecuzione del programma Per la gestione degli eventi di errore è stata realizzata la classe BlueException che fornisce i consueti metodi di creazione del messaggio di errore e di analisi del codice dell eccezione Le azioni di recovery forti, ossia il reset dello stack Bluetooth, il reboot e lo shutdown della macchina, sono state realizzate invocando funzioni proprie del sistema operativo

101 Capitolo 4 La dependability del profilo PAN Progettazione ed implementazione del client BlueTestPAN per Windows XP La preesistente versione del software BlueTestPAN per l ambiente Linux ha reso necessarie operazioni di porting del codice in due fondamentali direzioni: 1 riprogettazione e reimplementazione dei moduli per l instaurazione e la gestione di connessioni Bluetooth conformemente alle API fornite dal DK Broadcom ; 2 isolamento delle parti platform-dependent e riscrittura delle stesse in chiave Windows compliant 471 Gestione delle connessioni: il package BTWConnMng Per la gestione delle connessioni Bluetooth -con riferimento sia a connessioni L2CAP sia PAN- è stato realizzato un package, BTWConnMng, contenente le seguenti classi (cfr Figura 414): BtwConnection: è la classe centrale dell intera libreria Fornisce le primitive per la gestione sia delle connessioni PAN sia delle connessioni L2CAP e le funzioni per le fondamentali operazioni di Scan ed SdpSearch Essa implementa la classe astratta Connection esclusivamente al fine di tenere viva la coerenza con l analogo codice sviluppato in ambiente Linux BtwConnection deriva pubblicamente dalla classe CBtIf per la gestione delle operazioni di inquiry e ricerca dei servizi PAN: è la classe per la creazione, la gestione diretta e la distruzione di una connessione PAN Implementa la classe astratta CLapClient e

102 Capitolo 4 La dependability del profilo PAN 94 fornisce anche funzioni di controllo per lo stato della connessione La classe PAN è contenuta nella classe BtwConnection MyL2Cap: è la classe per la creazione, la gestione diretta e la distruzione di una connessione L2CAP Implementa la classe astratta CL2CapConn e fornisce funzioni di controllo per lo stato della connessione E classe contenitore (contenimento stretto) per la classe CL2CapIf, indispensabile per la comunicazione con il livello L2CAP, ed è contenuta nella classe BtwConnection CBAddrString: è una classe di utilità che fornisce le primitive per la conversione degli indirizzi Bluetooth in formato string standard e viceversa Exception: è la classe, già utilizzata nel codice sviluppato in ambiente Linux, per la definizione delle eccezioni e per la loro opportuna gestione Da essa derivano pubblicamente le classi: BTexception per la definizione delle eccezioni propriamente legate ad operazioni Bluetooth; SHMexception, mai utilizzata La struttura delle API ha spesso reso necessarie modifiche strutturali al codice inducendo inevitabili -ma non eccessive- differenze di comportamento tra il client Windows ed i client Linux: la gestione di una connessione PAN ne è un esempio significativo in quanto in ambiente Windows essa ha quale imprescindibile requisito l operazione di ricerca dei servizi che non è invece richiesta in ambiente Linux Altro punto di discrepanza tra i client è l impostazione del tipo di pacchetto Bluetooth da utilizzare per la connessione: le API BCM1000-BTW non consentono infatti di intervenire direttamente

103 Capitolo 4 La dependability del profilo PAN 95 CL2CapConn CL2CapIf Connection CBtIf CLapClient <<implements>> 1 <<implements>> <<implements>> MyL2CAP 1 BTWConnection PAN 1 «utility» CBdAddrString Exception BTWConnMng BtException SHMException Figura 414: Diagramma delle classi per la gestione delle connessioni su detto parametro contrariamente a quanto accade per BlueZ Effetto collaterale di situazioni del genere è stata spesso l introduzione di particolari azioni di recovery non necessarie in ambiente Linux 4711 Gestione delle eccezioni La gestione delle eccezioni ha costituito un aspetto importante nell ambito della progettazione e dell implementazione del package dal momento che eccezioni sollevate in fase di instaurazione e gestione delle connessioni sono quasi sempre sintomo di fallimento, e dunque di rilevanza fondamentale nei meccanismi di BlueTestPAN Con riferimento alla classe BTWConnection si è scelto di rimanere conformi, ove possibile, alle eccezioni sollevate dalla classe BlueConnection in ambiente Linux al fine di rendere più immediata l analisi comparativa dei dati relativi ai fallimenti di cui esse sono indice; la Figura 415 mostra le eccezioni sollevate dai metodi della classe

104 Capitolo 4 La dependability del profilo PAN 96 BTWException e le corrispettive eccezioni della classe BlueConnection Le eccezioni delle classi PAN e MyL2Cap sono schematizzate nelle Figure 416 e Da Linux a Windows Il porting delle codice per ciò che concerne le parti strettamente dipendenti dal sistema operativo e principalmente le chiamate di sistema, non si è rivelato un grosso onere grazie alla documentazione Microsoft decisamente ricca ed esaustiva a riguardo Le modifiche maggiormente rilevanti hanno riguardato l implementazione delle azioni di recovery ed in particolare è stato necessario realizzare le funzioni di cui alla Tabella 44 Recovery Action How to perform Windows Linux Reboot MySystemReboot() system(reboot) Shutdown MySystemShutdown() system(halt) Reset Stack WakeUpBTWStack() hciconfig ShutDownBTWStack() commands Tabella 44: Funzioni per l implementazione delle azioni di recovery Per la realizzazione di dette azioni è stato necessario ricorrere a particolari funzioni messe a disposizione dal sistema operativo; dettagli relativi all implementazione sono rimandati all Appendice A

105 Capitolo 4 La dependability del profilo PAN 97 Ö ØÙÚÛÜÜÙÝÞßÛÜ ÖÞàÚÛÜÜÙÝÞßÛÜ áùþûâû ãýýùäßûüù áùþûâû ãýýùäßûüù GetRssi() "getrssi: read conn "getrssi:there are no active GetRssi() info error" connections" getrssi: RSSI read error" SwtichRole() switch role request failed switch role command failed switch role: not connected Catch sulle eccezioni Prepare Prepare generate da switch handover() Handover() role PrepareHandover:Not connected Connect() Connect() ConnectWithPa connect: device ckettype() Connect "BtwConnection::Connect:Unable unavailable" (const to create L2CAPEvent " Connect(const string&) string&) "connect: Error opening device" "BtwConnection::Connect:WaitFor MultipleObjects failed " connect: unable to find device" Catch delle eccezioni generate da MyL2Cap::L2CAPConnect "connect : unable to SearchAndL2C SearchAndL2CAPConnect:Unable to create connection" APConnect() find an L2CAP PSM connect : already connected" Catch delle eccezioni generate da MyL2Cap::L2CAPConnect CompleteConnection: CompleteConnect bnep initialization PANConnect() "BtwConnection::PANConnect:Unab ion() le to switch role! failed "CompleteConnection: PANConnect(c PANConnect:Unable to switch Cannot create L2CAP onst string) role! socket" BtwConnection::SearchAndPANCon "CompleteConnection: SearchAndPAN nect:unable to find an L2CAP Bind failed" Connect() PSM "CompleteConnection: Failed to get L2CAP options CompleteConnection: Connection failed" CompleteConnection: unable to create connection" Disconnect() "Disconnect: Unable to close bnep connection" Disconnect() "Disconnect def: read conn info error" AboutConnect ion() "BtwConnection::AboutConnection :Unable to read connection info (PAN) Search() "Search:InquiryFailed" "BtwConnection::AboutConnection :Unable to read connection info (L2CAP) SearchAndConnec t() SDPSearch() SDPSearch (string) "Search: HCI device open failed" "SearchAndConnect: bnep initialization failed" "SearchAndConnect: Inquiry failed" "SearchAndConnect: Connection failed" "SDPSearch: SDP Search on AP failed" SDPSearch: SDP Search failed on device:" isconnected Figura 415: BTWConnection: eccezioni

106 Capitolo 4 La dependability del profilo PAN 98 èéêëìë PanConnect(BD_ADDR*, const GUID, CSdpDiscoveryRec& ) PanConnect(BD_ADDR* addr,csdpdiscoveryrec& sdprec) OnStateChange() GetConnResponse( ) Disconnect( ) åæç íîîéïðëñé "PAN::PanConnect:Server could not be reached" "PAN::PanConnect:Already Connected!!" "PAN::PanConnect:Unable to create connection" PAN::PanConnect:Server could not be reached" "PAN::PanConnect:Already Connected!!" "PAN::PanConnect:Unable to create connection" "PAN::Disconnect():ErrorClosingConnection Devices were not connected" "PAN::Disconnect():No open connections" Figura 416: PAN: eccezioni òùúûüû L2CAPConnect() OnConnected() OnRemoteDisconnected() L2CAPDisconnect ( ) òóôõö ø ýþþùÿ û ù "MyL2Cap::L2CAPConnect:ERROR - PSM assignment failed "MyL2Cap::L2CAPConnect:ERROR - not registered "MyL2Cap::L2CAPConnect:ERROR! L2CAP connection wasn't established Unable to assing CID MyL2Cap::L2CAPConnect:Unable to create ConnectionEvent "MyL2Cap::L2CAPConnect:Unable to create DisconnectionEvent "MyL2Cap::OnConnected:Unable to signal ConnectionEvent "MyL2Cap::OnRemoteDisconnected:Unable to signal DisconnectionEvent MyL2Cap::L2CAPDisconnect:no open connections Figura 417: L2CAP: eccezioni 473 Dettagli tecnici ed ambiente di sviluppo Il DK è stato sviluppato e testato in ambiente Visual C++ 60 ed è orientato prevalentemente allo sviluppo di applicazioni dotate di un interfaccia grafica implementata utilizzando le classi MFC (Microsoft Foundation Classes) 1 Per rimanere fedeli a quanto suggerito nella documentazione circa l ambiente di sviluppo, il client BlueTestPAN è stato sviluppato in ambiente Visual C++ 60 mentre l utilizzo delle classi MFC è stato bandito apportando un discreto numero di modifiche alle opzioni di compilazione indicate nella documentazione 1 Classi messe a disposizione da Microsoft per la realizzazione di applicazioni a finestre

107 Capitolo 4 La dependability del profilo PAN Risultati sperimentali I risultati sperimentali discussi nel presente Paragrafo si riferiscono ad una sessione di test caratterizzata dai parametri riportati in Tabella 45 in cui si è scelto di escludere i dispositivi palmari al fine di poter confrontare le prestazioni dei diversi sistemi operativi a parità di architettura hardware: nel testbed, infatti, non sono presenti palmari con sistema operativo Windows I dati a disposizione per l analisi consentono di effettuare considerazioni circa i modi di fallimento della rete, le operazioni maggiormente critiche e l efficacia di eventuali azioni di ripristino con riferimento ai singoli nodi Inoltre, uno studio e comparativo è reso possibile dall eterogeneità delle tecnologie software installate sui vari nodi Parametri di Test Periodo di raccolta 29 Agosto Ottobre 2005 Host Host Name Sistema Operativo Numero di fallimenti Verde Linux-Mandrake Win Windows XP SP2 122 Capatamarano Linux- Red Hat Fedora Core 519 Miseno Linux-Debian 189 Tabella 45: Caratteristiche della sessione di test A valle delle attività di analisi descritte nel dettaglio qui di seguito, si è riusciti a concludere che: i fallimenti legati al fallimento del binding delle socket L2CAP si devono a ritardi nell inizializzazione dell interfaccia BNEP nel kernel Linux ed, in misura minore, in ambiente Windows; in ambiente Windows le azioni di reset dello stack Bluetooth sono sufficienti a recuperare gran parte delle situazioni di errore rendendo sporadici gli eventi di reboot e shutdown dell host;

108 Capitolo 4 La dependability del profilo PAN 100 i fallimenti verificatisi durante una sessione di trasferimento dati hanno un carattere self-similar; la ricerca di un servizio non preceduta da una fase di inquiry ha un impatto decisamente negativo sull affidabilità dell applicazione 481 I fallimenti Mediante la cattura delle eccezioni generate dai client in attività sui vari nodi, è stato possibile individuare i tipi di fallimento occorrenti e stimare il peso percentuale di ognuno di essi sul numero totale di fallimenti I diversi tipi di fallimento sono identificati dal messaggio di errore prodotto in seguito al verificarsi di un eccezione e dunque nei grafici di Figura 418 è riportata la percentuale di fallimento in corrispondenza di ogni error message Ad un primo sguardo è già immediato osservare l occorrenza di fallimenti comuni a tutti i nodi e di fallimenti caratteristici invece del singolo host In Figura 418(a) è evidente come la maggior parte dei fallimenti sia da imputarsi al fallimento del binding della socket ed in particolare all indisponibilità dell indirizzo richiesto E ragionevole pensare che un occorrenza tanto massiccia di fallimenti di questo tipo sia dovuta ad un ritardo del sistema nel rendere attiva l interfaccia di rete ovvero che l errore sia dovuto ad un tentativo di bind su un interfaccia ancora non inizializzata Una discreta percentuale di fallimenti di questo tipo è stata registrata anche dal client Windows come si vede in Figura 418(d) Comune a tutti gli host, e con una percentuale certamente non trascurabile, è invece il fallimento registrato in fase di ricezione di un pacchetto segnalato dal messaggio recv timeout expired Fallimenti di questo tipo possono manifestarsi quale effetto di due cause: 1 perdita del pacchetto sul canale: un pacchetto inviato sul canale UDP

109 Capitolo 4 La dependability del profilo PAN 101 (a) Capatamarano, Linux Fedora (b) Miseno, Linux Debian (c) Verde, Linux Mandrake (d) Win, Windows XP SP2 Figura 418: Percentuale dei diversi tipi di fallimento

110 Capitolo 4 La dependability del profilo PAN 102 creato mediante l apertura della socket viene perso senza giungere a destinazione; 2 canale corrotto: il canale non è più attivo pertanto su di esso non viaggiano nè pacchetti dati nè pacchetti di controllo L utilizzo di un canale UDP per il trasferimento dei dati tra i nodi, e dunque di un protocollo di trasporto connection less, consente a fallimenti di questo tipo di gorgogliare a livello applicativo data l assenza di meccanismi di controllo a differenza di quanto accadrebbe se la trasmissione fosse affidata ad un protocollo connection oriented, quale ad esempio TCP Se da un lato i meccanismi di controllo dell errore messi a disposizione da quest ultimo, uniti alla ritrasmissione dei pacchetti in caso di errore, offrono garanzie sull integrità dei dati, dall altro introducono un inevitabile ritardo da tenere in conto nel caso di applicazioni con requisiti real time Un discorso analogo sussiste anche se si sceglie di affidare al livello applicativo il controllo dell errore e la gestione dei meccanismi di ritrasmissione Una visione complessiva dei tipi di fallimento registrati nell ambito dell intero testbed è illustrata in Figura 419 e schematizzata nella Figura 420 in cui sono stati evidenziati i dati di maggiore rilievo Sul totale numero di fallimenti registrati dall intero testbed, i fallimenti legati alle operazioni di binding risultano essere i più frequenti (circa il 36,50% + 218%) 2 mentre estremamente rari sono gli errori in fase d inquiry e di creazione della connessione PAN La Tabella 46 riporta le modalità di fallimento in relazione alla fase 2 sebbene i dati corrispondano in tabella a due righe differenti, essi sono da considerarsi effetto del medesimo errore Entry differenti sono esclusivamente dovute al fatto che in ambiente Windows non viene correttamente prelevato il codice di errore e dunque compare la dicitura No error

111 Capitolo 4 La dependability del profilo PAN 103 operativa cui esse sono relative prescindendo dai particolari messaggi di errore FASE Creazione della connessione Chiusura della connessione Scanning della rete Ricerca dei servizi Sessione IP L2CAP PAN L2CAP PAN MODALITÁ DI FALLIMENTO Connect, unable to create connection Switch role, request failed Switch role, command failed CompleteConnection: Connection Failed Disconnect PAN, devices were not connected Inquiry failed SDPSearch, NAP not found SDPSearch, Start Discovery Failed Bind Failed, unable to assign requested address Receive timeout expired Tabella 46: Schema riassuntivo delle modalità di fallimento Devices were not connected Figura 419: Tipi di fallimento sull intero testbed, visione 3D

112 Capitolo 4 La dependability del profilo PAN 104 Capata marano Mise no Verde Win % % % % Bind failed, SysErr: Cannot assign requested address 3650 Bind failed, SysErr: No error 218 CompleteConnection: Connection failed Disconnect: PAN::Disconnect():ErrorClosin gconnection Devices were not connected 425 SDPSearch: () Discovery for a given service failed on AP 010 SDPSearch: NAP Service not found on AP, timeout expired 188 SDPSearch: no NAP service found Search: Inquiry failed 010 connect : unable to create connection recv timeout expired switchrole: Switch role command failed switchrole: Switch role command failed 287 Figura 420: Tipi di fallimento sull intero testbed, schema

113 Capitolo 4 La dependability del profilo PAN Azioni di recovery I grafici in Figura 421 illustrano le azioni di recovery effettuate sui singoli host I dati riportati consentono di effettuare considerazioni interessanti circa l efficacia di determinate azioni al variare del sistema operativo In particolare va evidenziata la percentuale di azioni di reset dello stack Bluetooth: dalla Figura 421(d) si evince che le azioni di stack reset costituiscono la maggioranza delle azioni di recovery effettuate e che raramente è stato necessario operare azioni più severe quali ad esempio il reboot o lo shutdown del sistema Questa osservazione assume maggiore interesse se confrontata con i grafici di Figura 421(a) e Figura 421(b) in cui un azione di reset dello stack Bluetooth non ha mai portato alla risoluzione del fallimento ed in cui la percentuale di reboot del sistema è sensibilmente più elevata E evidente che il comportamento osservato in ambiente Windows risulta in quest ottica decisamente positivo vista la scarsa frequenza con cui è stato necessario agire sul sistema in maniera radicale Ulteriori e più interessanti considerazioni possono essere fatte con riferimento alle azioni delle tabelle in Figura 422 in cui è riportata la percentuale con cui una specifica azione di recovery è risultata efficace alla risoluzione di un determinato tipo di fallimento Dalla Figura 422(a) si evince, ad esempio, che il fallimento legato al binding della socket è risolto prevalentemente distruggendo la connessione Bluetooth e dunque che non è sufficiente l azione -più dolce- di reinizializzazione della socket Quest ultima si mostra risolutiva, invece, in un discreto numero di casi sull host Windows (cfr Figura 422(d)) e nella quasi totalità dei casi su tutti gli host per fallimenti occorsi in fase di ricezione ( recv timeout expired ) Ancora, dalla Figura 422(a) si deduce che nel 15,22% dei casi un azione di reboot è stata effettuata per il ripristino del sistema in seguito ad un bind failed e

114 Capitolo 4 La dependability del profilo PAN 106 U D P S o c k e t D i s t r u c t i o n - C r e a t i o n S y s t e m S h u t d o w n S y s t e m R e b o o t n 2 1, 9 3 2, 5 4, 0 5 S y s t e m R e b o o t 2 3, 8 9 B T d e s t - c r e a t a n d a p p l r e s t a r t e d 1 9 B T d e s t r u c t i o n - c r e a t i o n 6 7, (a) Capatamarano, Linux Fedora U D P S o c k e t D is t - C r e a t a n d S y s t e m R e b o o t 0, 5 3 U D P S o c k e t D is t r u c t io n - C r e a t io n 2 9, 1 S y s t e m S h u t d o w n 2, 6 5 S y s t e m R e b o o t n 2 7, 9 4 S y s t e m R e b o o t 3 3, 8 6 B T d e s t - c re a t a n d a p p l r e s t a r t e d 0, 5 3 B T d e s t r u c t io n -c r e a t io n 2 5, (b) Miseno, Linux Debian B T d e s t - c re a t a n d a p p l r e s t a r t e d 0,5 5 B T d e s t r u c t i o n - c r e a t io n 6,6 3 A p p li c a t i o n R e s t a r t e d n 2 B T S t a c k r e s e t 0,5 5 1,1 U D P S o c k e t D i s t r u c t i o n - C r e a t io n 1 4, 9 2 A p p l ic a t io n R e s t a r t e d 7 5,1 4 S y s t e m R e b o o t 1, (c) Verde, Linux Mandrake S y s t e m R e b o o t a n d a p p l r e s t 0,8 2 S y s t e m S h u t d o w n 3, 2 8 B T S t a c k re s e t 5 6,5 6 U D P S o c k e t D is t r u c t io n - C r e a t i o n 2 7,0 5 S D P S e a r c h r e p e a t e d s u c c e s s fu l ly 7,3 8 B T S t a c k r e s e t a n d a p p l r e s t S y s t e m R e b o o t 1, 6 4 3, (d) Win, Windows XP SP2 Figura 421: Azioni di recovery

115 Capitolo 4 La dependability del profilo PAN 107 che nel 1,16% dei casi per lo stesso motivo è stato necessario spegnere la macchina a testimonianza della notevole gravità del fallimento Al fine di acclarare la causa a monte di fallimenti di questo tipo, o meglio al fine di confermare l ipotesi che essi siano dovuti ad un ritardo nell inizializzazione dell interfaccia, si intende implementare una strategia di ripristino per cui, in seguito ad un eccezione del tipo bind failed si concede al sistema un passive time prima di ripetere il tentativo di binding in modo da consentire il completamento delle operazioni di attivazione Un altra interessante considerazione circa i fallimenti legati all insuccesso del binding può essere fatta con riferimento all host Windows Dalla Figura 422(d) si evince che nel 1,64% dei casi è stato necessario riavviare il sistema e altrettanto frequentemente arrestarlo Osservando il comportamento della macchina nell arco la sessione di test è stato possibile osservare che durante la normale esecuzione del client BlueTestPAN la comunicazione con il dongle Bluetooth USB viene improvvisamente interrotta impedendo al sistema di riconoscere l interfaccia: in maniera sistematica, conseguenza di una simile situazione è un fallimento del binding che non viene risolto se non con il restart della macchina Una giustificazione ragionevole di un simile comportamento potrebbe essere la presenza di problemi di comunicazione tra il sistema operativo ed i driver USB; l occorrenza casuale di comportamenti del genere lascia supporre che si sia in presenza di un guasto transiente

116 Capitolo 4 La dependability del profilo PAN 108 Recovery Action Error Message BT Connection destructioncreation and System Reboot BT Connection destructioncreation System Reboot System Reboot n2 System Shutdo wn UDP Socket destructio n-creation % % % % % % Bind failed, SysErr: Cannot assign requested address CompleteConnection: Connection failed SDPSearch: no NAP service found 058 connect : unable to create connection recv timeout expired switchrole: Switch role command failed - status : (a) Capatamarano, Linux Fedora Recovery Action Error Message BT Connection destructioncreation, and System Reboot BT Connection destructioncreation UDP Socket destructioncreation System Reboot System Reboot n2 System Shutdown UDP Socket destructioncreation, and System Reboot % % % % % % % SDPSearch: no NAP service found 159 connect : unable to create connection recv timeout expired switchrole: Switch role command failed (b) Miseno, Linux Debian

117 Capitolo 4 La dependability del profilo PAN 109 Recovery Action Error Message Applicatio n restarted Application restarted n2 BT Connection destructioncreation, and Application restarted BT Connection destructioncreation UDP Socket destructioncreation BT Stack RESET System Reboot % % % % % % % Complete Connection: Connection failed 110 Search: Inquiry failed 055 connect : unable to create connection recv timeout expired switchrole: Switch role command failed 055 (c) Verde, Linux Mandrake Recovery Action Error Message BT Stack RESET BT Stack RESET, and Application restarted BT Stack RESET, and Application restarted n3 SDPSearch repeated successfully System Reboot System Reboot, and Application restarted n4 System Shutdown UDP Socket destructioncreation % % % % % % % % Bind failed, SysErr: No error Disconnect: PAN::Disconnect() Devices were not connected 3525 SDPSearch: BtwConnection:: SDPSearch:Start Discovery for a given service failed on AP 082 SDPSearch: NAP Service not found on AP, timeout expired recv timeout expired (d) Win, Windows XP SP2 Figura 422: Azioni di recovery relative ai singoli fallimenti

118 Capitolo 4 La dependability del profilo PAN Fallimenti e Workload I dati raccolti consentono di effettuare misure relative ai legami tra i tipi di fallimento ed il particolare workload in esecuzione nel momento in cui essi si sono manifestati Più precisamente all atto della registrazione del fallimento nel file di log è stata codificata l attività corrente mediante uno tra i seguenti valori: CREATE CONNECTION, se il fallimento è avvenuto in fase di creazione della connessione L2CAP; DISCONNECTION, se il fallimento è avvenuto durante la chiusura di una connessione; SCANNING, se il fallimento è sopraggiunto durante la fase di scanning della piconet; SEARCHING, se il fallimento è avvenuto durante la ricerca di un servizio; FTP, se il fallimento è avvenuto durante il download di un file da un FTP server; MAIL, se il fallimento è avvenuto durante l inoltro o la ricezione di un messaggio di posta elettronica; STREAMING, se il fallimento è avvenuto durante l upload o il download di uno stream audio/video; P2P, se il fallimento è avvenuto durante una sessione di scambio file In Figura 423 sono riportati i grafici relativi ai singoli host sui quali è possibile avanzare alcune osservazioni Un numero significativo di fallimenti in fase di ricerca dei servizi si osserva esclusivamente per l host Windows

119 Capitolo 4 La dependability del profilo PAN 111 (cfr Figura 423(d)): un simile comportamento è giustificabile pensando al fatto che, per esigenze di programmazione imposte dallo stack Broadcomm utilizzato, è necessario che la creazione di una connessione PAN sia preceduta da una ricerca dei servizi e pertanto la frequenza con cui vengono effettuate operazioni di sdp search è sensibilmente più elevata rispetto a quanto accade negli host Linux Ancora con riferimento alla Figura 423(d) si osserva che il maggior numero di fallimenti si verifica in fase di disconnessione Dai messaggi di errore lanciati dalla primitiva di disconnessione è stato osservato che l errore è dovuto al tentativo di chiusura della connessione su un canale in realtà non più attivo: un comportamento del genere può essere imputato al fatto che l invocazione del metodo per la disconnessione segue un tempo di inattività di durata casuale, passive time, inserito per modellare l intervallo di tempo tra la fine della sessione operativa e la chiusura della connessione E ragionevole supporre che durante detto intervallo di inattività il sistema operativo, o anche lo stack Bluetooth, imponga la chiusura del canale in idle In Figura 424 sono riportate le percentuali di fallimento in corrispondenza dell attività corrente con riferimento all intero testbed Nelle prime colonne dello schema è immediato osservare un comportamento complementare tenuto dagli host con sistemi operativi differenti Lo stack BlueZ impone che la creazione di una connessione PAN sia esplicitamente preceduta dalla creazione della connessione a livello L2CAP ed è durante questa fase che si verificano i fallimenti indicati nella colonna Create Connection Viceversa le API Broadcom incapsulano la creazione della connessione L2CAP all interno del metodo per la creazione della connessione PAN e l operazione non lascia emergere alcun tipo di fallimento E dunque ragionevole concludere che il maggior numero di fallimenti regi-

120 Capitolo 4 La dependability del profilo PAN 112 Web 31,21 Streaming 13,87 SDP Search 0,58 P2P 43,16 MAIL FTP 2,32 2,12 Create Connection 6, (a) Capatamarano, Linux Fedora Web 1,06 Streaming 10,58 SDP Search 1,59 P2P 33,86 Create Connection 52, (b) Miseno, Linux Debian Web Streaming 2,21 2,76 P2P Create Connection 46,41 47,51 FTP Scanning 0,55 0, (c) Verde, Linux Mandrake Web 5,74 Streaming 15,57 P2P 26,23 SDP Search 16,39 FTP 0,82 Disconnection 35, (d) Win, Windows XP SP2 Figura 423: Percentuale dei fallimenti in relazione al profilo in esecuzione

121 Capitolo 4 La dependability del profilo PAN 113 Create connection Disconnection FTP Mail P2P SDP Search Scanning Streaming Web % % % % % % % % % Capatamarano Miseno Verde Win Figura 424: Percentuale dei fallimenti in relazione all attività corrente strati in ambiente Linux prima che la connessione PAN sia instaurata con successo, e quindi prima che la sessione possa avere inizio, è da imputarsi al maggior numero di passi richiesti dallo stack ovvero al fatto che è necessario sollecitare esplicitamente ognuno dei livelli dello stack protocollare di Bluetooth Per quanto concerne invece i fallimenti manifestatisi durante una sessione di trasferimento dati, i risultati lasciano trasparire, com era lecito aspettarsi, una distribuzione dei fallimenti legata alla probabilità di generazione delle singole attività oltre che alla lunghezza delle sessioni: si veda infatti la bassa percentuale di fallimenti durante una sessione di mailing contrapposta all elevato numero di fallimenti registrati durante sessioni WEB e P2P 484 Le sessioni L attenzione del presente Paragrafo è concentrata sulla distribuzione temporale dei fallimenti nell arco di una sessione Dal momento che la distribuzione della dimensione dei file scambiati è una distribuzione heavy-tailed, ossia una distribuzione in cui la probabilità che la variabile assuma valori elevati non è trascurabile, non è raro che i client siano coinvolti in sessioni di scambio anche molto lunghe Sebbene una sessione eccessivamente lunga sia poco

122 Capitolo 4 La dependability del profilo PAN 114 verosimile dal punto di vista del reale utilizzo di Bluetooth si è scelto di prendere ugualmente in esame il caso al fine di sollecitare il canale in maniera più spinta e testarne in qualche maniera la capacità di sopravvivenza In Figura 425 è riportata, per l intero testbed, la concentrazione temporale dei fallimenti con riferimento all attività corrente ed è facile osservare come -indipendentemente dal tipo di attività- la maggior parte dei fallimenti sia concentrata all inizio di ogni sessione Per evidenziare ulteriormente un simile comportamento si è scelto di effettuare una classificazione delle sessioni in base alla loro durata come schematizzato in Tabella 47 Sessione Long Session Short Session Very Short Session Durata Massima 24 h, 15 min 2 h 7,36 min Tabella 47: Classificazione delle sessioni in base alla durata Frequenza di fallimento Workload Durata della sessione (min) Figura 425: Frequenza dei fallimenti in relazione alla durata della sessione e all attività corrente In quest ottica può essere interessante osservare il comportamento dei

123 Capitolo 4 La dependability del profilo PAN 115 singoli host in funzione della durata delle sessioni illustrato in Figura 426(a) per una Short Session ed in Figura 426(b) per una Very Short Session Da esse è possibile dedurre la tendenza generale di concentrazione di fallimento all inizio di ogni sessione, indipendentemente quindi dal sistema operativo, ma va evidenziato il fatto che per l host Windows detta concentrazione sia totale in quanto sono praticamente assenti fallimenti successivi alla fase iniziale di trasmissione Un comportamento simile è stato osservato anche con riferimento ad una sessione di test in cui è stato messo in esercizio il profilo di basso livello LowLevelTest In Figura 427 è riportata la percentuale di fallimento in funzione del numero di pacchetti scambiati: è evidente la concentrazione degli errori nella fase iniziale del trasferimento I dati cui si fa riferimento nella Figura 427 sono relativi ad una sessione di test di poche settimane pertanto è il risultato è da considerarsi del tutto preliminare

124 Capitolo 4 La dependability del profilo PAN 116 Frequenza di fallimento Host Durata della sessione (min) (a) Short Session Frequenza di fallimento Host Durata della sessione (sec) (b) Very Short Session Figura 426: Frequenza dei fallimenti nell arco di una sessione

125 Capitolo 4 La dependability del profilo PAN 117 Figura 427: Frequenza dei fallimenti in relazione al numero di pacchetti in una sessione LowLevelTest 4841 La distribuzione dei fallimenti nel tempo Osservazioni qualitative circa distribuzione dei fallimenti nel tempo possono essere condotte con riferimento alla Figura 428, in cui è riportata la percentuale di fallimenti nel tempo con riferimento ad una sessione P2P osservata su diversi intervalli temporali E interessante notare come l andamento non vari al variare della scala temporale su cui è valutato e pertanto è ragionevole supporre che i fallimenti si distribuiscano secondo un processo self-similar, ovvero che le caratteristiche del fenomeno siano invarianti per traslazioni, espansioni e compressioni Sebbene non siano state fatte stime quantitative, ad un primo sguardo sembra inoltre che la distribuzione dei fallimenti nel tempo segua la distribuzione della dimensione dei file scambiati durante la sessione Un analisi più accurata di quest aspetto potrà confermare l intuizione

126 Capitolo 4 La dependability del profilo PAN 118 Durata della sessione (min) (a) Long Session Durata della sessione (min) (b) Short Session Durata della sessione (sec) (c) Very Short Session Figura 428: Andamento della percentuale dei fallimenti nell arco di una sessione P2P

127 Capitolo 4 La dependability del profilo PAN Scan ed sdp search I grafici riportati in questo Paragrafo consentono di stimare l incidenza delle operazioni di scan ed sdp search sui fallimenti del sistema Come esposto al Capitolo 3, infatti, ogni client esegue dette operazioni in accordo ad una certa distribuzione di probabilità al fine di emulare un comportamento simile al vero La Figura 429 illustra la frequenza di fallimento di ogni host in relazione al fatto che siano state effettuate o meno le operazioni di scanning e ricerca dei servizi, e lascia emergere la tendenza, comune a tutti gli host, a fallire maggiormente qualora si avvii la procedura di sdp search senza aver prima effettuato uno scanning della piconet Risultati del genere forniscono un utile indicazione per lo sviluppo di applicazioni affidabili in quanto evidenziano una significativa differenza tra la teoria e l effettivo comportamento dei dispositivi: un applicazione in cui ogni operazione di ricerca dei servizi sia preceduta da uno scanning risulterà maggiormente dependable Una stima quantitativa dei fallimenti in corrispondenza delle operazioni di scan ed sdp search con riferimento all intero testbed è deducibile dai dati in Figura 430

128 Capitolo 4 La dependability del profilo PAN 120 scan Sdp search scan Sdp search (a) Capatamarano, Linux Fedora (b) Miseno, Linux Debian scan Sdp search scan Sdp search (c) Verde, Linux Mandrake (d) Win, Windows XP SP2 Figura 429: Frequenza di fallimento in corrispondenza di scan e/o sdp search, visione 3D SDPsearch Scan 0 1 % % Figura 430: Percentuale dei fallimenti in corrispondenza di scan e/o sdp search, schema

129 Capitolo 5 Progettazione di un testbed RFCOMM RFCOMM fornisce l astrazione di un canale di comunicazione seriale e costituisce ad oggi lo standard de facto per il supporto al trasferimento di file tra dispositivi Bluetooth oltre ad offrire la possibilità di accesso alla rete La quasi totalità delle applicazioni offre meccanismi per lo scambio di contenuti tra nodi Bluetooth: trasferimenti di immagini, clip audio e business card costituiscono una cospicua fetta del utilizzo di telefoni cellulari e dispositivi palmari Il presente capitolo illustra la progettazione di un testbed per la valutazione dell affidabilità del protocollo di trasporto seriale e dei profili ad esso legati Ad una breve parte introduttiva in cui si descrivono i fondamenti di RFCOMM e l architettura del testbed, segue una dettagliata descrizione della progettazione del software per la generazione del traffico e la descrizione di un protocollo per la gestione delle comunicazioni all interno della rete di cui in chiusura si riporta una valutazione sperimentale Dettagli implementativi sono riportati con riferimento all ambiente Windows XP 51 Il livello RFCOMM RFCOMM (Radio Frequency oriented emulation of serial COMports on a pc) è un semplice protocollo di trasporto che emula il comportamento di una porta di trasmissione seriale sul livello L2CAP e si basa sullo standard ETSI TS 0710 Una connessione RFCOMM coinvolge due nodi, endpoints, legati da un canale virtuale di comunicazione Le modalità di instaurazione 121

130 Capitolo 5 Progettazione di un testbed RFCOMM 122 Figura 51: Profili basati su RFCOMM e chiusura di una connessione Bluetooth RFCOMM sono stabilite dal Serial Port Profile (SPP) da cui dipendono gli altri profili RFCOMM-based come è illustrato in Figura 51 Ad oggi la totalità delle applicazioni Bluetooth fa uso di canali RF- COMM per il trasferimento di file, tramite il protocollo OBEX, e - con riferimento a telefoni cellulari e dispositivi palmari- per l accesso alla rete a mezzo di un dispositivo gateway tramite il profilo DUN (Dial Up Networking) La conversione di traffico IP in traffico Bluetooth gestibile dal livello RFCOMM avviene grazie al protocollo PPP (Point to Point Protocol) che trasforma i pacchetti IP in un flusso di traffico seriale (serial data stream) RFCOMM, oltre ad essere presente su tutti i dispositivi dotati di interfaccia Bluetooth, costituisce dunque l alternativa al profilo PAN per l accesso alla rete Internet ed in quest ottica cresce l interesse per la valutazione della sua affidabilità 52 Il testbed Il testbed per lo studio della dependability del livello RFCOMM e dei profili ad esso legati è stato progettato nella direzione della massima eteroge-

131 Capitolo 5 Progettazione di un testbed RFCOMM 123 neità sia con riferimento alle piattaforme hardware sia ai sistemi operativi (cfrfigura 52) Rimanendo fedeli all architettura del testbed logico per lo studio della dependability di Bluetooth di cui alla Figura 32, con particolare riferimento alla valutazione su RFCOMM vanno particolarizzate le figure di CN Client Node e SN Server Node Contrariamente a quanto già descritto per il testbed PAN in cui la rete ha una topologia a stella senza la possibilità di alternanza di ruoli tra client e server, per il testbed RFCOMM si è scelto di realizzare un architettura di rete a maglia completamente connessa in cui quattro nodi comunicano secondo il paradigma peer-to-peer come si vede dalla Figura 52 Ogni dispositivo, pertanto, potrà assumere il duplice ruolo di CN o SN a Linux Peer Win CE Peer Windows XP peer Symbian Peer Figura 52: Architettura del testbed seconda dello stato della rete e, a differenza di quanto accade per il testbed PAN, su tutti i nodi dovrà essere installato il medesimo software applicativo per la generazione di dati emulati, BlueTestRfcomm

132 Capitolo 5 Progettazione di un testbed RFCOMM Progettazione del software BlueTestRfcomm Un primo diagramma di alto livello per la descrizione delle funzionalità richieste è riportato in Figura 53 CLIENT sdpsearch Connection Communicate mode Mode=client Exception Exception Recovery Exception DECISION Mode=client StopSession Mode =server Exception Exception Exception Mode=server SERVER PublService Waiting Communicate Figura 53: Diagramma degli stati di alto livello di un nodo Bluetooth Ogni nodo del testbed può permanere nello stato CLIENT o nello stato SERVER: nel primo esso dovrà essere in grado di ricercare un servizio prestabilito, connettersi al server ed avviare la comunicazione, nel secondo -inveceil dispositivo dovrà rendere pubblici i servizi che è in grado di offrire, attendere connessioni in ingresso ed avviare la comunicazione Al termine di una connessione il nodo passa nello stato DECISION in cui si valuta lo stato da assumere per il successivo ciclo: la modalità con cui viene stabilita l alternanza tra gli stati riveste un ruolo fondamentale nell ambito della gestione del testbed e sarà dettagliatamente discussa al Paragrafo 531 In caso di errori il nodo giunge nello stato RECOVERY in cui si prova a ripristinare il normale funzionamento del sistema

133 Capitolo 5 Progettazione di un testbed RFCOMM Protocollo di orchestrazione dei peer La natura peer to peer(p2p) delle comunicazioni tra i nodi introduce problematiche di sincronizzazione e alternanza di ruoli con riferimento alla generazione di traffico emulato Se per il testbed PAN la presenza di un unico server impone implicitamente i ritmi della comunicazione, l architettura del testbed RFCOMM solleva la necessità di un meccanismo di sincronizzazione esterno e dunque di un protocollo di orchestrazione La topologia a maglia completamente connessa di una rete a N nodi impone che il numero massimo di connessioni possibili sia pari a N (N 1)/2 mentre -assunto N pari- il numero massimo delle connessioni attive è ovviamente pari a N/2 Con riferimento alla rete di Figura 52, quindi, i nodi potranno connettersi a coppie e la massima attività della rete si avrà in corrispondenza della connessione contemporanea di due coppie Sulla scorta delle precedenti osservazioni, il protocollo è stato studiato con lo scopo di ottimizzare, massimizzandolo, l utilizzo della rete Detti: - T c [i] il tempo di permanenza del nodo i-simo in stato client; - T s [i] il tempo di permanenza del nodo i-simo in stato server; - T idle [i] il tempo per cui un nodo non è coinvolto in connessioni attive; - T idlenet = i T idle[i] i = 1N il tempo per cui nella rete non vi sono connessioni attive; - N c [i, j] il numero di connessioni tra il nodo i-simo ed il nodo j- simo; - t c [i, j] la durata di una connessione tra il nodo i-simo ed il nodo j-simo;

134 Capitolo 5 Progettazione di un testbed RFCOMM T c [i, j] = j t c[i, j] i = 1N il tempo totale di connessione tra il nodo i-simo ed il nodo j-simo; gli obiettivi del protocollo possono essere così sintetizzati: N c [i, j] = N c [i, k] i = 1N, j k e per j, k i (51) T c [i, j] = T c [i, k] i = 1N, j k e per j, k i (52) R[i] = T c[i] = 1 i = 1N (53) T s [i] T idlenet Min! (54) Le relazioni 51 e 52 mirano a rendere equa la partecipazione dei nodi alle attività della rete e ad evitare che le connessioni siano instaurate sempre tra gli stessi dispositivi aumentando il T idle [i] dei nodi non coinvolti e di conseguenza il T idlenet La 53, invece, punta a disciplinare il comportamento dei singoli nodi facendo in modo che ognuno di essi permanga per intervalli di tempo confrontabili nello stato CLIENT e nello stato SERVER in quanto uno sbilanciamento dei tempi di permanenza potrebbe polarizzare in maniera errata i risultati dell analisi Al raggiungimento della 54 concorre, oltre al soddisfacimento delle relazioni precedenti, la configurazione iniziale della rete Al fine di individuare una soluzione subottima del problema, si è scelto di procedere alla formulazione delle euristiche descritte nelle sezioni che seguono La prima, denominata Versione Base, gestisce la comunicazione tra i nodi implementando la semplice alternanza tra i ruoli client-server e, sulla scorta di valutazioni sperimentali, si è rivelata estremamente sensibile ad errori transienti dei singoli nodi L evoluzione del protocollo si concretizza nella seconda euristica che adotta, invece, una strategia di controllo adattativo

135 Capitolo 5 Progettazione di un testbed RFCOMM Versione Base La strategia di orchestrazione adottata nella prima versione del protocollo è schematizzata in Figura 54 Client A Server B SDP SEARCH WAITING SERVICE FOUND CONNECT REQUEST CONNECTED CONNECTED DISCONNECT REQUEST DISCONNECTED DISCONNECTED CONNECT REQUEST Client B CONNECTED Server A WAITING Client C SDP SEARCH SERVICE FOUND CONNECTED DISCONNECTED Server C WAITING CONNECT REQUEST CONNECTED Server D WAITING CONNECT REQUEST CONNECTED DISCONNECT REQUEST DISCONNECTED CONNECT REQUEST Client C CONNECT REQUEST Switch role time TEMPO Figura 54: Orchestrazione dei peer Lo stato della rete in ogni istante è descritto dal vettore N-dimensionale NetConf in cui ogni componente è rappresentativa dello stato di un singolo nodo Assumendo N pari, la configurazione iniziale della rete è scelta in modo tale che il numero di dispositivi in stato server eguagli quello dei nodi client in modo da massimizzare la probabilità che, allo startup, non vi siano nodi in idle; all istante t 0 quindi S i N/2 NetConf [i] = C otherwise (55) assumendo, ad esempio, un ordinamento dei nodi in base al BD ADDR Mediante una procedura di polling i dispositivi in stato client effettuano una operazione di sdp search per la ricerca di un servizio prestabilito e, in seguito alla scoperta dello stato su un dispositivo server, vengono avviate le procedure di pairing A valle dell instaurazione delle connessioni, i nodi

136 Capitolo 5 Progettazione di un testbed RFCOMM 128 client procedono con l invio di pacchetti sul canale Bluetooth coerentemente con il profilo selezionato In caso di trasmissione conclusa con successo, i nodi effettuano un inversione di ruolo dopo aver atteso un tempo casuale indicato con t switchrole, e assunto uniformemente distribuito: t switchrole U[0, 3]sec (56) Nel caso in cui la trasmissione tra client e server fallisca si procede semplicemente alla ritrasmissione del pacchetto A transitorio esaurito, la rete si porterà in una condizione di regime in cui il numero di dispositivi client e server in ogni istante non è prevedibile vista la natura casuale dei tempi di trasmissione e di switchrole: per evitare situazioni di stallo si è scelto di adottare un meccanismo basato sui timeout sia lato client sia lato server Una strategia del genere prevede quindi, per ogni nodo, una sistematica alternanza tra i ruoli di client, disciplinata dallo scadere di un timeout, e server e non implementa esplicite soluzioni per la gestione delle connessioni 5312 Versione Adattativa La seconda alternativa proposta per l orchestrazione è una strategia di natura adattativa tramite cui poter controllare on-line l andamento dei parametri di interesse Analogamente alla versione base, la configurazione iniziale della rete è tale che il numero di dispositivi in stato client sia pari al numero di nodi server Le azioni di controllo on-line implementate agiscono separatamente sul rapporto R e sui parametri di connessione N c e T c Logica di controllo dell andamento di R Per controllare l andamento del rapporto tra i tempi di permanenza in

137 Capitolo 5 Progettazione di un testbed RFCOMM 129 stato CLIENT ed in stato SERVER si è scelto di adottare una strategia di controllo in retroazione grazie a cui lo stato del nodo, e dunque l ingresso del sistema, coincide con l uscita di un blocco controller Dopo un numero di cicli prefissato in cui il sistema viene lasciato in evoluzione libera, ovvero in cui ogni nodo passa alternativamente dallo stato CLIENT allo stato SERVER e viceversa, si valuta il valore del rapporto Ts/Tc e viene determinato lo stato prossimo del nodo secondo la legge: NextMode = S C se 1 R < ɛ se 1 R ɛ (57) Switched se ɛ < 1 R < ɛ Il valore di ɛ, ovviamente scelto minore di uno, determina la sensibilità del protocollo Qualora il valore del rapporto sia bilanciato il contatore del numero di cicli viene azzerato, viceversa se lo scostamento dal valore di riferimento è, in modulo, superiore ad ɛ l azione di controllo è ripetuta ad ogni ciclo fino a riportare R nella fascia di valori consentita Il diagramma di flusso di Figura 55 chiarisce quanto appena esposto Logica di controllo dell andamento dei parametri di connessione Allo scopo di rendere equa la partecipazione dei nodi alle attività della rete e dunque al fine di evitare che due o più nodi monopolizzino i canali di trasmissione, si è scelto di implementare una strategia di controllo basata sul bilanciamento del numero o dei tempi di connessione per ogni coppia di nodi Ad un dispositivo in stato CLIENT che debba avviare le operazioni di ricerca del servizio viene fornita una lista degli indirizzi ordinata secondo la particolare strategia scelta: il primo indirizzo della lista corrisponde al server con cui il nodo è stato connesso il

138 Capitolo 5 Progettazione di un testbed RFCOMM 130 Time Balancing Main Program Decide_Mode START NUMCICLI=30 COUNTER=0 DO JOB() COUNTER++ NO COUNTER > NUMCICLI SWITCH_MODE COUNTER=0 YES CONTROLLER CALCULATE R YES BALANCED R NO DECIDE_NEXT_MODE COUNTER++ Figura 55: Azione di controllo per il bilanciamento dei tempi minor numero di volte, se si è optato per un controllo sul numero delle connessioni, o per il minor tempo se invece si vuole agire sui tempi di effettiva comunicazione Una simile strategia risulta completamente trasparente ai dispositivi in stato server oltre ad alleggerire il carico decisionale dei nodi client demandando dunque ogni responsabilità al dispositivo controller In Figura 56 è riportato il diagramma di flusso per il bilanciamento del numero di connessioni 532 Emulazione del traffico: i profili di carico La modalità di generazione di traffico emulato risente profondamente dell architettura della rete ed in particolare della natura peer-to-peer dei nodi che ne fanno parte L attività di valutazione della dependability di RFCOMM assume un accezione leggermente differente da quanto visto per il testing del profilo PAN in quanto mira, piuttosto che alla valutazione complessiva

139 Capitolo 5 Progettazione di un testbed RFCOMM 131 Connection Managment Client Controller NextServer= FirstFound Connect (Next_Server) Update_Param eters() Decide_Next_Se rver(strategy) Figura 56: Azione di controllo per la gestione delle connessioni delle operazioni Bluetooth, allo studio dell affidabilità del canale virtuale di trasporto seriale In quest ottica BlueTestRfcomm prescinde dalle operazioni di inquiry ed sdp search riferendosi ad una struttura di piconet statica in cui ogni nodo è a conoscenza dell identità degli altri dispositivi presenti e procede alla richiesta di un servizio prestabilito senza mai effettuare operazioni di sdp browsing Il focus dell emulazione si sposta pertanto sulla generazione di pacchetti da far viaggiare su un canale RFCOMM e sulle operazioni di creazione, distruzione e gestione dello stesso A tal fine si è scelto di emulare due profili di carico: il primo, di più alto livello, per il testing dei profili Bluetooth basati su RFCOMM e maggiormente utilizzati in scenari di utilizzo reali (OPP, FTP, DUN), il secondo corrispondente al LowLevelTest di cui al Paragrafo 322 per la valutazione dell affidabilità del canale Nell elenco che segue si riportano brevemente le caratteristiche dei singoli workload 1 Relativamente ai profili OPP ed FTP, i parametri di generazione del traffico sono stati determinati in accordo a quanto descritto al Para-

140 Capitolo 5 Progettazione di un testbed RFCOMM 132 grafo 322 relativamente ad una sessione di trasferimento file Per quanto concerne il profilo DUN (Dial Up Networking), invece, si è ritenuto opportuno apportare una modifica alla modalità di generazione del traffico IP di cui al Paragrafo 322 Il profilo prevede infatti due principali scenari applicativi: l utilizzo di un gateway 1 per l accesso in dial-up alla rete Internet e l utilizzo di un gateway per la ricezione di dati da parte di un DT (Data Terminal, tipicamente si tratta di PC o PDA) Senza ledere la generalità del test si è scelto di far riferimento esclusivamente al primo scenario simile, per la natura delle sessioni, allo scenario NAP del profilo PAN Data la diversa natura dei dispositivi coinvolti, però, si è scelto di emulare gli stessi protocolli di rete ma di limitare la dimensione dei file scambiati In particolare con riferimento ai protocolli STREAMING, FTP e P2P, piuttosto che d 10 Pareto(11), si assume d Pareto(11) (58) 2 Con riferimento al livello RFCOMM la dimensione dei pacchetti si assume pari alla massima MTU (1691byte) ed il numero di pacchetti per ogni sessione è scelto pari a Le interfacce L eterogeneità del software di base che caratterizza il testbed ben si presta ad una progettazione mediante interfacce con l intento di definire il comportamento esterno delle classi da implementare prescindendo dai dettagli 1 modem o telefoni cellulari

141 Capitolo 5 Progettazione di un testbed RFCOMM 133 implementativi Per la realizzazione delle funzionalità richieste a BlueTestRfcomm sono state individuate le seguenti interfacce: RfcommConnection Interfaces, pensate per definire le operazioni deputate all instaurazione ed alla gestione della connessione RFCOMM, sia lato client sia lato server, tra i vari dispositivi Prescindendo dunque dai particolari meccanismi di comunicazione propri delle singole piattaforme (ad esempio il meccanismo socket-based) le interfacce sono progettate per fornire, tra gli altri, i metodi generali di cui alla Figura 57 «interfaccia» RfcommConnectionClient +PrepareConnection() +StartConnection() +SetConnectionParameters() +CloseConnection() +SendData() +ReceiveData() +SetUpChannel() «interfaccia» RfcommConnectionServer +PrepareConnection() +StartConnection() +SetConnectionParameters() +CloseConnection() +WaitForIncomingConnection() +PublService() (a) RfcommConnectionClient (b) RfcommConnectionServer Figura 57: RfcommConnectionInterfaces TimeManager Interface (cfr Figura 58), pensata per la gestione della tempificazione, fondamentale per i meccanismi basati sugli eventi e per la sincronizzazione dei peer (cfr Paragrafo 531) La gestione dei timer è, in generale, strettamente dipendente dalla piattaforma pertanto anche in questo caso l interfaccia impone i metodi che ogni classe che la realizzi dovrà implementare adoperando meccanismi propri del particolare sistema operativo Random Generator Interface (cfr Figura 59), pensata per la generazione delle variabili casuali secondo determinate distribuzioni di pro-

142 Capitolo 5 Progettazione di un testbed RFCOMM 134 «interfaccia» TimeManager +StartTimer() +StopTimer() +ResetTimer() +GetCurrentTime() +GetElapsedTime() Figura 58: TimeManagerInterface babilità ed utile in fase di emulazione del traffico su rete Le operazioni richieste alle classi che la realizzano risulteranno poco dipendenti dalla piattaforma «interfaccia» RandGenerator +SetDistributionParameter() +GetDistributionParameters() +GenerateVariableofSpecifiedDistribution() Figura 59: RandomGeneratorInterface Profiles Interface (cfr Figura 510), pensata per la gestione delle operazioni proprie dei profili basati su RFCOMM In particolare, si intende considerare i profili per lo scambio di file OPP (Object Push Profile) ed FTP (File Transfer Profile) che utilizzano il protocollo OBEX ed i profili DUN e LAN Access per l accesso alla rete; si vuole inoltre implementare un profilo per il testing dell affidabilità del canale RFCOMM grezzo, LowLevelTest «interfaccia» ProfilesManager +SetProfile() +SetProfilePreferences() +PerformProfileOperations() «interfaccia» FileExchangeProfiles +PushObject() +CreateObject() +TransferFile() «interfaccia» LowLevelTest +SetPacketMTU() +SetPacketNumber() +PerformErrorChecking() «interfaccia» NetworkAccessProfile +SelectAccessPoint() +PerformNetworkActivities() +SelectNetworkActivities() Figura 510: ProfilesInterface

143 Capitolo 5 Progettazione di un testbed RFCOMM 135 Exception Interface (cfr Figura 511), pensata per offrire una definizione omogenea di generazione dei messaggi di errore e delle funzioni per il trattamento delle eccezioni Analogamente a quanto osservato per la gestione dei timer, le classi deputate alla gestione delle eccezioni implementeranno metodi strettamente dipendenti dalla piattaforma «interfaccia» ExceptionManager +GetExceptionMessage() +GetExceptionCode() +ReportExceptionOnLogFile() +GetExceptionSystemInfo() Figura 511: ExceptionInterface L identificazione delle interfacce del sistema risulta di grande aiuto all atto dell implementazione del codice nei diversi ambienti Esse forniscono le linee guida per la progettazione delle classi in quanto ne stabiliscono il comportamento percepibile dall esterno; la sezione che segue illustra il passaggio dall individuazione delle interfacce alla progettazione, e alla successiva implementazione, delle classi che le realizzano con riferimento all ambiente Windows XP 54 BlueTestRfcomm in ambiente Windows XP Il primo passo verso la specializzazione dei comportamenti definiti in fase di progettazione è stato fatto con riferimento all ambiente Windows XP mediante la progettazione e la successiva implementazione delle classi brevemente descritte nel seguito 541 Classi per la comunicazione Bluetooth su RFCOMM Per la messa in opera della comunicazione Bluetooth basata su RFCOMM si è scelto di utilizzare l interfaccia socket-based messa a disposizione da

144 Capitolo 5 Progettazione di un testbed RFCOMM 136 Microsoft; in Figura 512 sono riportati i diagrammi delle classi realizzate per l astrazione dei meccanismi di più basso livello e delle operazioni proprie di Bluetooth BlueServerSock -SOCKET s -int portnumber -BTH_ADDR clientaddress -string clientstringaddress +BlueServerSock() #BlueBind() : void #BlueListen() : void #BlueAccept() : BlueServerSock #CloseBlueServerSock() : void #BlueSetService() : void +BlueDeleteService() : void +BlueSetPortNumber() : void +BlueSetPortNumber() : int +BlueGetClientAddress() : string BlueSock -BTH_ADDR ServerAddress -BTH_ADDR LocalAddress -int portnumer -string LocalStringAddress; -string ServerStringAddress; -SOCKET s +BlueSock() #CloseBlueSock() : void #BlueSetMaxMtu() : int #BlueConnect() : void #BlueSend() : void #BlueReceive() : void #BlueRecv() : int +BlueSetPortNumber() : void +BlueGetPortNumber() : int +GetSocket() +BlueGetLocalAddress() : string +BlueGetServerAddress() : string #BlueServiceSearch() : void #BlueStartInquiry() : void «interfaccia» RfcommConnectionServer +PrepareConnection() +StartConnection() +SetConnectionParameters() +CloseConnection() +WaitForIncomingConnection() +PublService() +SetupChannel() «interfaccia» RfcommConnectionClient +PrepareConnection() +StartConnection() +SetConnectionParameters() +CloseConnection() +SendData() +ReceiveData() +SetupChannel() +Inquiry() +SDPSearch() Figura 512: Classi per la comunicazione Bluetooth su RFCOMM La classe BlueSock offre i metodi per la gestione delle socket lato client e per la realizzazione delle procedure di inquiry e ricerca dei servizi La presenza di costruttori sovraccaricati (non riportati nel diagramma per esigenze di leggibilità) fornisce la possibilità di specificare in fase di creazione dell oggetto i parametri caratteristici sia delle socket in senso stretto sia delle operazioni Bluetooth quali, ad esempio, il particolare servizio o l indirizzo del server La classe BlueServerSock, invece, è deputata alla gestione delle socket lato server e alle operazioni di pubblicazione dei servizi Bluetooth: tramite la funzione BlueSetService(), invocata dal metodo

145 Capitolo 5 Progettazione di un testbed RFCOMM 137 PublService() offerto dall interfaccia, è possibile rendere pubblici i servizi offerti dal dispositivo e registrarlo nel database dei servizi SDP in modo tale che esso possa essere individuato quale provider da ogni dispositivo client La pubblicazione dei servizi è necessaria sia nel caso di servizi predefiniti sia di servizi personalizzati (custom) 542 Classe per la gestione dei timer In ambiente Windows numerose sono le classi (nell ambito del framework Net) e le funzioni messe a disposizione per la gestione dei timer Dal momento che le esigenze del software BlueTestRfcomm si limitano alla valutazione degli intervalli di tempo scanditi dalle operazioni di start e stop si è scelto di utilizzare il meccanismo più semplice basato sull utilizzo della funzione GetTickCount() grazie a cui è possibile ottenere il tempo trascorso, in millisecondi, dall istante di avvio della macchina L utilizzo di un meccanismo tanto semplice è sufficiente al caso di BlueTestRfcomm in quanto non è necessaria sincronizzazione temporale tra i nodi e dunque non sorgono problemi legati all eventuale disallineamento dei clock In Figura 513 è il riportato il diagramma della classe BlueTimer() BlueTimer -starttimestamp : BlueTimerDWORD -stoptimestamp : BlueTimer DWORD -timeelapsed : BlueTimer DWORD +BlueTimer() #BlueStartTimer() : void #BlueStopTimer() : void #BlueResetTimer() : void #BlueGetTimeElapsed() : BlueTimer DWORD #BlueGetCurrentTime() : BlueTimer DWORD «interfaccia» TimeManager +StartTimer() +StopTimer() +ResetTimer() +GetCurrentTime() +GetElapsedTime() Figura 513: Classe per la gestione dei timer

146 Capitolo 5 Progettazione di un testbed RFCOMM Classe per la gestione delle eccezioni La gestione delle eccezioni è stata realizzata in maniera estremamente platformdependent utilizzando i meccanismi per la scrittura di codice C++ managed messi a disposizione da Net e le classi di logging per la realizzazione di un logger personalizzato gestito alla stessa stregua dei logger Windows predefiniti Una scelta simile è giustificata da un lato dall intenzione di usufruire delle enormi potenzialità del codice managed, dall altro dalla possibilità di poter processare i dati di sistema e quelli di utente esattamente alla stessa maniera evitando di dover implementare successive routine di parsing In Figura 514 è il riportato il diagramma della classe BlueException() BlueException -message : BlueException <gcroot> String* -code : int -messcode : int -UserLog : BlueException static gcroot <EventLog*> -StringMsg : BlueException = String* +BlueExcpetion() +GetExceptionCode() : int +GetExceptionMessCode() : int «interfaccia» ExceptionManager +GetExceptionMessage() +GetExceptionCode() +ReportExceptionOnLogFile() +GetExceptionSystemInfo() Figura 514: Classe per la gestione delle eccezioni Lo snapshot di Figura 515 illustra il log di applicazione generato dalla classe BlueException() Per la realizzazione del logger personalizzato, BlueLog, è stata utilizzata la classe EventLog del namespace SystemDiagnosticLog 544 Implementazione del protocollo di orchestrazione 5441 Implementazione della versione base Per valutare il grado di performance della strategia proposta al Paragrafo 5311 è stata realizzata una versione prototipale del testbed di Figura 52 costituita da quattro PC equipaggiati con sistema operativo Microsoft Windows XP Le connessioni Bluetooth sono state realizzate utilizzando le classi

147 Capitolo 5 Progettazione di un testbed RFCOMM 139 Figura 515: BlueLog di cui al Paragrafo 541 mentre per la gestione dei parametri temporali e l orchestrazione dei peer è stata utilizzata la classe BlueTimer di cui al Paragrafo 542 Nei frammenti di codice che seguono è descritta una pseudo-implementazione del protocollo

148 Capitolo 5 Progettazione di un testbed RFCOMM 140 //Server int server( out TempoDiConnessione){ try{ Listing 51: Server ApriSocketServer(); Bind(); PubblicaServizio(); Listen(); while(1){ AttendiConnessioniInIngresso(); if (TimeoutScaduto) { ChiudiSocketServer(); Tconnessione =0; EsciDalCiclo; } } RiceviPacchetto(); if ( PacchettoRicevuto) { CalcolaTempoDiConnessione(); ChiudiSocketServer(); ChiudiSocketClient(); } return( ConnessioneCorrettamenteTerminata); } catch( BlueException ){ SollevaEccezione(); } catch(){ SollevaEccezione(); } return ( TimeoutScaduto); }

149 Capitolo 5 Progettazione di un testbed RFCOMM 141 //Client int client(out IndirizzoServer) { try{ Listing 52: Client LeggiFileDegliIndirizzi(); InserisciIndirizziInLista(); GeneraPacchettoDaInviare(); IndirizzoCorrente = InizioLista; while( ViSonoIndirizziNellaLista) { ApriSocketClientIndirizzoCorrente(); try{ ConnettiIndirizzoCorrente(); InviaPacchetto(); ChiudiSocketClient(); EsciDalCiclo(); }catch(blueexception ex){ } if( ErroreInConnessione) IndirizzoCorrente ++; else SollevaEccezione(); } if( FineLista) return ( NessunServerTrovato); } catch(blueexception exc) { SollevaEccezione(); } catch(){ SollevaEccezione(); } return ( ConnessioneTerminataConSuccesso); }

150 Capitolo 5 Progettazione di un testbed RFCOMM 142 // Programma chiamante int main( CondizioneIniziale) { ApriDll(); mode = CondizioneIniziale; GeneraTempoDiStart(0,2); ApriFileDiLog(); Sleep( TempoDiStart); WriteLog( TempoDiStart); Listing 53: Programma Chiamante while(1) { try{ DichiaraVariabili(); Inizializza Timer(); GeneraTempoDiSwitchrole(0,5); if (mode== S or mode == s ){ AvviaTimer(); StartServer( TIMEOUT); StopTimer(); CalcolaTempoServer(); EsaminaCondizioneUscitaDelServer(); if( TIMEOUT scaduto) WriteLog( TimeoutScaduto); else WriteLog( ConnConcl, TempoServer, TConnEff); } WriteLog( switchrole); Switchrole(); AzzeraTempoServer(); Sleep( TempoDiSwitchrole); } if(mode== C or mode== c ) { ResetTimer(); AvviaTimer(); while( TimeoutClient non scaduto) { StartClient(); EsaminaCondizioneUscitaDelClient(); if( ConnessioneConclusa) EsciDalCiclo; else if (non ha trovato alcun server){ CalcolaTempoPerLaRicerca(); WriteLog( TempoPerLaRicerca); Sleep( tempocasuale); } } StopTimer(); CalcolaTempoClient(); if( ConnessioneConclusa) WriteLog( TempoClient); else WriteLog( TimeoutScaduto); WriteLog( switchrole); Switchrole(); AzzeraTempoClient(); Sleep( TempoDiSwitchrole); } } catch( BlueException) { GestisciEccezioniBluetooth(); }catch() {GestisciEccezioniGeneriche(); }ChiudiDll(); ChiudiLogFile(); return 0; }

151 Capitolo 5 Progettazione di un testbed RFCOMM Implementazione della versione adattativa L implementazione del protocollo nella sua versione adattativa è stata realizzata utilizzando gli strumenti di sviluppo, le librerie di comunicazione ed il testbed fisico già utilizzati per la versione base (cfr Paragrafo 5441) La responsabilità delle azioni di controllo è stata assegnata alle classi Controller (cfr Figura 516(a)) e ClientConnManager (cfr Figura 516(b)) rispettivamente per la gestione dei tempi e dei parametri di connessione Controller -switched : bool = false -currentmode : Controller Mode = mode -ratio : float = 0 -tsqueue : Controller Coda -tcqueue : Controller Coda -file <static> : Controller ofstream +Controller() +DecideMode() : Controller Mode +updateclienttype() : void +updateservertime() : void +is_switched() : bool -Recorder() : void -switchmode() : Controller Mode (a) Classe Controller ClientConnManager -mynodemap : ClientConnManager NodeMap = false -strategy : ClientConnManager Strategy = mode +ClientConnManager() +get_connectiontime() : ClientConnManagerDWORD +get_numberofconnection() : void DWORD +setstrategy() : void +update() : bool (b) Classe ClientConnManager Figura 516: Diagrammi delle classi Il listato qui di seguito riporta la pseudo-implementazione del programma chiamante

152 Capitolo 5 Progettazione di un testbed RFCOMM 144 Listing 54: Programma Chiamante int main( CondizioneIniziale) { InizializzazioneParametriComeVersioneBase(); IstanziaControllore C; IstanziaConnectionManager CCM; Contatore count =0; while(1) { try{ DichiaraVariabili(); IstanziaControllore(); IstanziaConnectionManager(); Inizializza Timer(); GeneraTempoDiSwitchrole(0,5); if (mode== S or mode == s ){ AvviaTimer(); StartServer( TIMEOUT); StopTimer(); CalcolaTempoServer(); C UpdateServerTime(); EsaminaCondizioneUscitaDelServer(); if( TIMEOUT scaduto) WriteLog( TimeoutScaduto); else WriteLog( ConnConcl, TempoServer, TConnEff); } WriteLog( switchrole); Switchrole(); AzzeraTempoServer(); Sleep( switchroletime); } if(mode== C or mode== c ) { ResetTimer(); AvviaTimer(); CCMGetList(); while( TimeoutClient non è scaduto) { StartClient(); EsaminaCondizioneUscitaDelClient(); if( ConnessioneConclusa) EsciDalCiclo; else if (non ha trovato alcun server){ CalcolaTempoPerLaRicerca(); WriteLog( TempoPerLaRicerca); Sleep( tempocasuale); } } StopTimer(); CalcolaTempoClient(); CCM Update( indirizzoserver, tempodiconnessione); C UpdateClientTime(); if( ConnessioneConclusa) WriteLog( TempoClient); else WriteLog( TimeoutScaduto); WriteLog( switchrole); Switchrole(); AzzeraTempoClient(); Sleep( switchroletime); } CDecideMode(count); count ++; } catch( BlueException) { GestisciEccezioniBluetooth(); }catch() {GestisciEccezioniGeneriche(); } RilasciaRisorseComeversioneBase(); return 0; }

153 Capitolo 5 Progettazione di un testbed RFCOMM Valutazione sperimentale del protocollo di orchestrazione in ambiente Win XP Al fine di valutare le prestazioni del protocollo di orchestrazione sono state effettuate ripetute sessioni di test in cui la fase di effettiva comunicazione tra i nodi ha previsto il semplice scambio di buffer di caratteri di dimensione casuale e dunque senza la realizzazione di un particolare profilo La sessione di test cui si fa riferimento nel seguito è stata articolata in due fasi della medesima durata, circa 25 ore, una per ogni versione del protocollo 551 Versione Base Analizzando i dati raccolti durante l esecuzione del programma di test è stato possibile dedurre i valori dei parametri per la valutazione delle performance del protocollo nella sua versione base In Figura 517 è riportato il valore del rapporto R per ogni nodo del testbed: è facile osservare come la soluzione si allontani decisamente dall ottimo per tre dei quattro nodi 1 0,9 0,915 0,8 0,7 0,6 0,5 0,443 0,4 0,3 0,2 0,1 0,339 0,354 0 ALCOR KRISAORE MEGRES MIME Figura 517: Valore del rapporto Ts/Tc La Figura 518(a) illustra il numero di connessioni per ogni coppia di

154 Capitolo 5 Progettazione di un testbed RFCOMM 146 nodi, mentre in Figura 518(b) sono riportati i tempi di connessione effettiva, ossia i tempi al netto dei tempi di attesa per i nodi server e dei tempi di ricerca per i nodi client Dall osservazione dei grafici è possibile evincere l accentuata sensibilità del protocollo ad errori transienti che possono sopraggiungere durante le attività della rete: un server che sia momentaneamente non rilevabile dai nodi client -sia per problemi legati al canale Bluetooth sia per un ritardo nella risposta alla richiesta di connessione- può essere estromesso dall intera comunicazione per tutto il tempo che ogni client impiega a comunicare con tutti i rimanenti server della lista E evidente inoltre come N c e T c siano significativamente lontani dai valori di riferimento Lo schema di Figura 519 riassume in forma tabellare i parametri più significativi della sessione di test Il tempo di idle è stato stimato mediamente pari a circa il 20% del tempo totale di attività per ogni nodo 552 Versione Adattativa L analisi dei dati relativi ad una sessione di test in cui è stato utilizzato il protocollo nella sua versione adattativa ha fornito i risultati illustrati nel presente Paragrafo In Figura 520 è riportato l andamento del rapporto R in funzione del tempo: a transitorio estinto, il sistema si porta a regime stabilizzando R intorno al valore di riferimento I valori sull asse delle ascisse sono stati troncati per evidenziare esclusivamente l intervallo di tempo maggiormente significativo Dalla Figura 520(b) è possibile osservare come, in presenza di grossi scostamenti dal valore di riferimento, l algoritmo sia in grado di ristabilire, pur se lentamente, il valore di R Per la sessione di test in esame si è scelta quale strategia per il controllo dei parametri di connessione l azione basata

155 Capitolo 5 Progettazione di un testbed RFCOMM 147 ALCOR KRISAORE MEGRES MIME MEGRES ALCOR KRISAORE ALCOR KRISAORE MIME MEGRES MIME ALCOR MEGRES MIME KRISAORE (a) Numero di connessioni per ogni coppia di nodi MEGRES ALCOR KRISAORE MEGRES MIME ALCOR KRISAORE ALCOR KRISAORE MIME MEGRES MIME ALCOR MEGRES MIME KRISAORE (b) Tempo di connessione per ogni coppia di nodi (msec) Figura 518: Parametri di connessione

156 Capitolo 5 Progettazione di un testbed RFCOMM 148 HOST ALCOR KRISAORE REMOTE KRISAORE MIME MEGRES ALCOR MIME MEGRES TS (ms) TC (ms) TCONN! " 218, , , , , ,2553 NUM_CONN &')* &($$ ')' &$&& (%#% &$*$ MEGRES MIME MIME KRISAORE ALCOR KRISAORE ALCOR MEGRES , , , , , ,0694 '+) &*(# '(# (()% &%#' #$% Figura 519: Schema riassuntivo della sessione di test sul numero di connessioni; in Figura 521 sono riportati i dati relativi ad ogni nodo del testbed Dal grafico di Figura 522 è più immediato osservare la bassa varianza del numero di connessioni per ogni singolo nodo del testbed Il tempo di idle è stato stimato mediamente pari a circa il 5% del tempo totale di attività per ogni nodo

157 Capitolo 5 Progettazione di un testbed RFCOMM 149 Alcor Ts/Tc (a) Alcor Krisaore Ts/Tc (b) Krisaore Megres Ts/Tc Mime Ts/Tc (c) Megres (d) Mime Figura 520: Andamento del rapporto R

158 Capitolo 5 Progettazione di un testbed RFCOMM 150 REMOTE /6/0 /01203 NUM_CONN 5, 45,- REMOTE FGHI@ =C=> =>?@>A NUM_CONN D<E :B; :;< (a) Alcor (b) Krisaore REMOTE QWXRN UOUS MNOPQRNS NUM_CONN JVL JKT JKL REMOTE `ija] ebf]b_ \]^_`a]b NUM_CONN gh[ Ycd YZ[ (c) Megres (d) Mime Figura 521: Numero di connessioni, schema ALCOR KRISAORE MEGRES MIME MEGRES ALCOR KRISAORE ALCOR KRISAORE MIME MEGRES MIME ALCOR MEGRES MIME KRISAORE Figura 522: Numero di connessioni

159 Conclusioni Al termine del lavoro di ricerca e sperimentazione condotto nell ambito del presente lavoro di tesi, tanti sono gli spunti di riflessione, le considerazioni ed i risultati raggiunti ma altrettanto numerosi risultano gli aspetti ancora inesplorati o che necessitano di ulteriori approfondimenti Lo studio sperimentale della dependability di Bluetooth ha riguardato in particolare i profili PAN ed i profili basati su RFCOMM al variare delle architetture hardware, dei sistemi operativi e dello stack Bluetooth Relativamente al profilo PAN è stato realizzato un testbed eterogeneo costituito da nodi fissi e mobili su cui sono installati i sistemi Windows, nella versione XP SP2, e Linux in diverse distribuzioni (Mandrake, Fedora Core, Debian) e con tre differenti versioni del kernel 2 Da un analisi dei dati relativi ad una sessione di test della durata di 42 giorni, è stato possibile individuare le modalità di fallimento della rete, valutare l efficacia delle azioni di ripristino on-line ed evidenziare alcune sequenze di operazioni critiche Inoltre l eterogeneità del testbed ha consentito di effettuare valutazioni comparative Con riferimento alle modalità di fallimento, l analisi ha lasciato emergere sia comportamenti comuni a tutti i nodi della rete, tra cui il fallimento in fase di ricezione di un pacchetto IP, sia fallimenti relativi esclusivamente ai singoli host come ad esempio il fallimento in fase , , mdk 151

160 152 di disconnessione registrato esclusivamente in ambiente Windows Interessanti considerazioni possono essere fatte con riferimento ai fallimenti legati all insuccesso del binding della socket su IP che hanno costituito il 56% delle situazioni di errore in ambiente Linux Fedora Core ed il 18,03% in ambiente Windows Dall osservazione dei dati relativi alle azioni di recovery in grado di ripristinare il comportamento del sistema in seguito a fallimenti di questo tipo, è stato osservato -con riferimento all host Linuxche nella maggioranza dei casi il fallimento è risolto mediante la distruzione e la successiva ricreazione della connessione Bluetooth e che, quindi, il fallimento è probabilmente imputabile ad un ritardo nell attivazione dell interfaccia BNEP ad opera del sistema operativo Considerazioni analoghe possono essere ripetute con riferimento al nodo con sistema operativo Windows in cui il fallimento è quasi sempre risolto mediante il reset dello stack Bluetooth In misura minore, ma comunque non trascurabile, sono stati rilevati fallimenti in fase di ricerca del servizio e di creazione della connessione L2CAP Le azioni di recovery implementate per il recupero a caldo di situazioni di errore si sono dimostrate spesso risolutive per un discreto numero di fallimenti E stato interessante osservare come azioni di recovery forti, ovvero reboot e shutdown della macchina in seguito a fallimenti gravi, siano stati molto più frequenti in ambiente Linux che in ambiente Windows probabilmente per via della struttura più robusta del kernel di quest ultimo Azioni di creazione e distruzione della socket hanno spesso risolto, pur se in misura differente sui vari nodi, fallimenti in fase di ricezione Con riferimento agli errori in fase di binding, sulla scorta di quanto detto pocanzi, è stata implementata 3 un azione di ripristino ad hoc per cui in seguito al fallimento si ripete l ope- 3 al momento esclusivamente sull host Linux Fedora Core

161 153 razione dopo un breve tempo di idle: da una prima osservazione dei dati, la percentuale degli insuccessi risulta drasticamente ridotta Ulteriori osservazioni possono essere condotte circa la distribuzione dei fallimenti nel tempo Nell arco di una sessione in cui è generato traffico emulativo di protocolli di rete si è osservata una distribuzione dei fallimenti self-similar e coerente con la distribuzione di generazione del traffico Infine, quanto alle operazioni critiche, è stato possibile appurare -quale tendenza generale di tutti i nodi della rete- che effettuare in sequenza le operazioni di scanning della rete e di ricerca del servizio riduce notevolmente la percentuale di fallimento rispetto al caso in cui le stesse operazioni siano effettuate singolarmente oppure non effettuate affatto Per la valutazione della dependability con riferimento al livello RF- COMM il lavoro è ad uno stadio ancora preliminare Nell ambito del presente lavoro di tesi si è conclusa la fase di progettazione del testbed e del software per la generazione di traffico emulato su canali RFCOMM oltre che l implementazione in ambiente Windows La natura peer-to-peer della rete ha reso necessaria l implementazione di un protocollo per l orchestrazione dei nodi che ne massimizzasse i parametri di utilizzo Il protocollo è stato realizzato in una prima versione base, che ne ha evidenziato un accentuata sensibilità agli errori, ed in una seconda versione, migliorativa, basata su strategie di controllo adattativo Valutazioni sulla bontà del protocollo sono state rese possibili dalla sperimentazione dello stesso su una versione prototipale del testbed Sviluppi Futuri Sulla scorta dei risultati raggiunti e delle questioni che il presente lavoro di tesi è riuscito a sollevare, l attività di ricerca proseguirà nell immedia-

162 154 to futuro con l approfondimento dello studio della dependability del profilo PAN e con la messa in esercizio dei workload per ciò che concerne il livello RFCOMM Con riferimento al profilo PAN è imminente la raccolta di dati in quantità significativa per la valutazione dell azione di recovery implementata per il mascheramento del fallimento in fase di binding Inoltre, restano da approfondire i risultati relativi ai fallimenti rilevati grazie al profilo LowLevelTest, messo in opera da poche settimane e non sull intero testbed Le differenze di comportamento messe in evidenza dall analisi comparativa relativamente ai sistemi operativi suggerisce la necessità di un approfondimento teorico e tecnico sulla natura degli stessi al fine di fornire giusitficazioni plausibili ai risultati ottenuti Con particolare solerzia, si intende integrare nel testbed un dispositivo palmare equipaggiato con sistema operativo Windows CE, al fine valutare la dependability del profilo su piattaforme Windows mobili e di estendere il raggio dell analisi comparativa Per quanto concerne RFCOMM, è attualmente in corso il porting in ambiente Linux del codice di BlueTestRfcomm implementato in ambiente Windows; il passo successivo riguarderà l implementazione dello stesso per dispositivi Symbian e Windows CE Inoltre, mediante l utilizzo di un programma di sniffing per reti Bluetooth si intende effettuare un analisi dettagliata del traffico con il un duplice intento di valutare la percentuale di fallimento al variare del tipo di pacchetto utilizzato a livello Baseband e, in accordo con il LowLevelTest, valutare l entità e la natura degli errori presenti su canali BNEP ed RFCOMM in grado di compromettere l integrità dei dati

163 Appendice A How to A1 BlueZ BlueZ è lo stack Bluetooth ufficiale in ambiente Linux ed è integrato nel kernel a partire dalla versione 26 Oltre ad una serie di moduli relativi ai vari livelli Bluetooth, BlueZ mette a disposizione anche diversi strumenti di monitoring utili per attività di testing e debug A11 Installazione ed inizializzazione dello stack Per l installazione di BlueZ è necessario disporre delle librerie riportate in Tabella A1 Libreria Descrizione Tipo bluez-hcidump-15targz Packet Dumping Utility O bluez-libs-24targz Bluetooth Stack M bluez-utils-23targz Connection tools M bluez-sdp-14targz Service Discovery Protocol M bluez-pan-11targz Pan Profiling Support O M=mandatory, O=optional wwwbluezorg/download Tabella A1: File per l installazione di BlueZ Per estrarre il contenuto dei file è sufficiente digitare, da qualsiasi posizione, il comando: tar zxvf packetname 155

164 Appendice A How to 156 Per avviare l installazione, digitare da ogni cartella generata dall estrazione: /configure make install Per assicurarsi che l installazione sia andata a buon fine, assicurarsi che il file /etc/modulesconf contenga le righe: probeall usb-interface usb-uhci ehci-hcd alias net-pf-31 bluez alias bt-proto-0 l2cap alias bt-proto-2 sco alias bt-proto-3 rfcomm alias bt-proto-4 bnep alias tty-ldisc-15 hci-vhci Se l installazione è effettuata su un dispositivo mobile è necessario collegare i driver UART al livello HCI digitando il comando seguente: hciattach /dev/ttysb0 bcsp A12 Comandi per la gestione di una sessione Bluetooth Il comando per testare lo stato dell interfaccia HCI e configurarla opportunamente è: hciconfig Per eseguire un applicazione Bluetooth è necessario lanciare il demone hcid digitandone semplicemente il nome da shell Il demone per la ricerca dei servizi è invece sdpd Una volta lanciato il demone hcid è possibile utilizzare i comandi di Tabella A2 A13 Creazione di una connessione PAN Prima di poter creare una connessione PAN è necessario creare una connessione a livello L2CAP: hcitool cc --role=m --ptype=< ptype > <BDAddress> Il demone per la gestione di una connessione PAN (a patto di aver installato l opportuno pacchetto) è il demone pand che va invocato a valle del caricamento del modulo BNEP:

165 Appendice A How to 157 Comando hcitool inq hcitool scan hcitool con hcitool cc <> hcitool dc < BDADDR > hcitool dev hcitool name < BDADDR > l2ping < BDADDR > hcitool sr <BDADDR> <role> Descrizione Inquiry della piconet Scanning della piconet Verifica delle connessioni attive Creazione di una connessione Disconnessione Informazioni sul dispositivo locale Nome del dispositivo specificato Stato della connessione L2CAP Cambio di ruolo (master-slave o viceversa) Tabella A2: Comandi hcitool modprob bnep A questo punto, è stata realizzata la virtualizzazione di un interfaccia di rete -bnep0- e per attivare il profilo PAN è necessario digitare i seguenti comandi: pand --listen --role GN (on master side) pand --connect <BDAddress> (on slave side) Per verificare che il profilo sia stato correttamente inizializzato e che l interfaccia BNEP sia pronta, è possibile digitare il comando ifconfig -a E inoltre possibile configurare in maniera personalizzata l interfaccia BNEP assegnando un determinato indirizzo IP, ad esempio: ifconfig bnep

166 Appendice A How to 158 A2 Sviluppo di applicazioni per Windows XP Con il rilascio del SP2 (Service Pack 2) Microsoft ha reso disponibile una nuova versione del Software Development Kit (SDK) per lo sviluppo di applicazioni Windows compliant Per l installazione dell SDK è necessario procedere al download dei file all URL A21 MicrosoftNet Microsoft NET Framework è un componente del sistema operativo Microsoft Windows che fornisce modelli di programmazione per la generazione, il deployment e l esecuzione di applicazioni Web, applicazioni smart client e Web services Si compone di: Windows NET Framework per creare ed eseguire applicazioni Web, applicazioni per client intelligenti e Web Services Questi componenti facilitano l integrazione, condividendo i dati e le funzionalità in rete mediante protocolli standard indipendenti dalla piattaforma quali XML, SOAP e HTTP Esso è composto da Common Language Runtime (CLR)e da un insieme unificato di librerie di classi; Strumenti di sviluppo come Microsoft Visual Studio NET 2003, che fornisce un ambiente di sviluppo integrato (IDE) per ottimizzare la produttività degli sviluppatori con Windows NET Framework; Una serie di server, inclusi Microsoft Windows Server 2003, Microsoft SQL Server e Microsoft BizTalk Server, per l integrazione, l esecuzione, l utilizzo e la gestione dei Web service e delle applicazioni Web; Software client, quali Windows XP, Windows CE e Microsoft Office XP Per lo sviluppo in ambiente Windows è stato utilizzato l ambiente IDE Visual Studio Net 2003 Affinché le applicazioni così generate possano correttamente funzionare su una macchina Windows su cui non sia installato l ambiente di sviluppo è necessario installare il supporto a run-time disponibile all URL

167 Appendice A How to f d1e7cf3a3\\&displaylang=en L utilizzo del WindowsNET framework è risultato particolarmente utile nell implementazione di classi per il logging personalizzato di eventi e per la scrittura di managed code in C++ A22 Sviluppo di applicazioni Bluetooth Nell ambito del nuovo Platform SDK di cui appena discusso è disponibile il supporto allo sviluppo di applicazioni Bluetooth la cui documentazione è reperibile all URL /bluetooth_start_pageasp Per la gestione dei dispositivi e l effettuazione di operazioni Bluetooth è possibile utilizzare due diversi approcci: 1 Managing devices directly by using nonsocket Bluetooth interfaces; 2 Using the Windows Sockets interface Vista la maggiore flessibilità e facilità di utilizzo delle interfacce, nel presente lavoro di tesi è stato adottato l approccio socket-based nonostante esso renda possibile l accesso diretto esclusivamente a livello RFCOMM Le funzioni per la gestione dell interfaccia socket sono le stesse dell interfaccia socket standard cui vanno ovviamente forniti, però, opportuni parametri strettamente legati a Bluetooth Oltre alle funzioni per la gestione dell interfaccia sono inoltre presenti funzioni per l implementazione di operazioni proprie di Bluetooth quali ad esempio le operazioni di scanning A221 Esempio di una tipica applicazione Bluetooth Per rendere immediate le modalità di utilizzo delle API qui di seguito si riportano gli step fondamentali per la realizzazione di una semplice applicazione e una breve descrizione delle funzioni utilizzate ad ogni passo Si supponga di voler realizzare un applicazione client-server in cui il dispositivo client, dopo aver effettuato un operazione di scanning procede alla ricerca di un particolare servizio ed alla creazione di una connessione con il dispositivo server

168 Appendice A How to 160 Inizializzazione e chiusura DLL Per abilitare le funzioni Bluetooth, ma più in generale l interfaccia socket, è necessario aprire la DLL (Dinamic Link Library) WS2_32dll A tal fine è necessario invocare la funzione int WSAStartup( WORD wversionrequested, //versione LPWSADATA lpwsadata ); Per la chiusura della DLL al termine del programma è invece necessario invocare la funzione int WSACleanup(void); Creazione di una socket Bluetooh Per creare una socket Bluetooth è sufficiente invocare la funzione socket() nel modo seguente: SOCKET s = socket (AF_BTH, SOCK_STREAM, BTHPROTO_RFCOMM); La funzione è definita nel file Winsock2h e richiede il file di libreria Ws2lib Applicazione Server Il comportamento di un normale server nel caso di socket connectionoriented, quali sono le socket Bluetooth, è quello di Figura A1(a) Per un server Bluetooth, il comportamento si modifica come illustrato in Figura A1(b) dal momento che esso è necessariamente tenuto a pubblicare un servizio La funzione per la pubblicazione di un servizio è la WSASetService() definita nel file Winsock2h e va invocata specificando in ingresso il flag RNRSERVICE_REGISTER INT WSASetService( LPWSAQUERYSET lpqsreginfo, WSAESETSERVICEOP essoperation, DWORD dwcontrolflags ); Il frammento di codice che segue illustra una possibile implementazione per l applicazione server:

169 Appendice A How to 161 Socket() Socket() Bind() Listen() Accept() SetService() Bind() Listen() Accept() Receive() Receive() (a) Socket Server Stream (b) Socket Stream Bluetooth Server Figura A1: Stream Server //Bluetooth server #include <winsock2h> #include <Ws2bthh> #include <BluetoothAPIsh> void server(){ SOCKADDR_BTH sa; memset (&sa, 0, sizeof(sa)); saaddressfamily=af_bth; saport=portnumber; sockaddr *paddr = (sockaddr*)&sa; SOCKET s = socket (AF_BTH, SOCK_STREAM, BTHPROTO_RFCOMM); if(s == INVALID_SOCKET) { //error treatment } if(bind(s, (SOCKADDR *)&sa, sizeof(sa)) == SOCKET_ERROR) { //error treatment } //strutture dati necessarie alla pubblicazione del servizio WSAQUERYSET service; memset(&service, 0, sizeof(service)); servicedwsize = sizeof(service); servicelpszserviceinstancename = "My Service"; servicelpserviceclassid = &serviceid; servicedwnumberofcsaddrs = 1; servicedwnamespace = NS_BTH;

170 Appendice A How to 162 CSADDR_INFO csaddr; memset(&csaddr, 0, sizeof(csaddr)); csaddrlocaladdrisockaddrlength = sizeof(sockaddr_bth); csaddrlocaladdrlpsockaddr = paddr; csaddrisockettype = SOCK_STREAM; csaddriprotocol = BTHPROTO_RFCOMM; servicelpcsabuffer = &csaddr; if (0!= WSASetService(&service, RNRSERVICE_REGISTER, 0)){ //error treatment} if(listen (s,5)==invalid_socket){ //error treatment} SOCKET AcceptSocket=accept(s,NULL,NULL); } //DO JOB NOW! Applicazione Client Per effettuare le operazioni di scanning, è necessario che il dispositivo client invochi in sequenza le funzioni WSALookupServiceBegin() e WSALookupServiceNext() i cui prototipi sono riportati qui di seguito: INT WSALookupServiceBegin(LPWSAQUERYSET lpqsrestrictions, DWORD dwcontrolflags, LPHANDLE lphlookup); INT WSALookupServiceNext(HANDLE hlookup, DWORD dwcontrolflags, LPDWORD lpdwbufferlength, LPWSAQUERYSET lpqsresults); Le medesime funzioni vanno invocate anche per le procedure di ricerca dei servizi a patto di specificare i giusti valori per i parametri di ingresso e uscita Al fine di non appesantire la trattazione si rimanda, per i particolari strettamente tecnici, all URL bluetooth/discovering_bluetooth_devices_and_servicesasp A valle della scoperta del servizio voluto, il comportamento del client Bluetooth non differisce da quello di un normale socket client in quanto dovrà esclusivamente invocare la funzione connect() specificando il numero di porto corrispondente al servizio e trasferire i dati da inviare invocando la funzione send() A23 Reboot e Shutdown di una macchina Windows Per lo spegnimento o il riavvio di una macchina, locale o remota, Windows mette a disposizione due funzioni del Microsoft Platform SDK che accettano

171 Appendice A How to 163 in ingresso una serie di flag di opzione (tra cui il flag per specificare se si tratta di reboot o shutdown) ed un flag, ReasonFlag, per definire i motivi in seguito ai quali è stata invocata la funzione La prima, ExitWindowsEx() restituisce un valore non appena l azione di reboot o shutdown è stata avviata lasciando che essa proceda in maniera asincrona rispetto agli altri processi in esecuzione sulla macchina Essa è dunque più indicata per applicazioni interattive in cui l utente può effettivamente controllare che l operazione vada a buon fine: è possibile, infatti, che applicazioni al momento in esecuzione i cui dati non siano stati salvati interrompano il processo di spegnimento in attesa di un salvataggio da parte dell utente Una simile circostanza può essere evitata specificando tra i flag di opzione il flag EWX_FORCE che forza l arresto incondizionato di tutti i processi attivi La seconda funzione, InitiateSystemShutdownEx(), è maggiormente indicata per applicazioni non interattive e consente di registrare l evento di reboot o shutdown nel log di sistema Prima di invocare ciascuna delle due funzioni è necessario impostare i privilegi necessari Esempi dettagliati dell uso delle funzioni e della gestione dei privilegi è reperibile presso base/how_to_shut_down_the_systemasp; base/displaying_the_shutdown_dialog_boxasp

172 Appendice A How to 164 A3 Broadcomm: lo stack BCM1000-BTW Prerequisiti L installazione del DK (Development Kit) Broadcom richiede i seguenti requisiti di sistema: Microsoft Windows 98, Me, 2000, Xp (administrator privileges); Microsoft Visual C++ 60 o Microsoft Visual Studio 60 SP 5; 64 Mb Memoria RAM; 50 Mb spazio libero su hard disk A31 Ambiente di sviluppo ed istruzioni di compilazione L ambiente di sviluppo richiesto per lo sviluppo di applicazioni che utilizzino il BCM1000-BTW DK è Microsoft Visual C++ 60 Figura A2: Snapshot di Visual C++ 60 Durante la fase di sviluppo delle applicazioni che utilizzano le API Broadcom numerose sono state le problematiche di linking Il DK è infatti pensato per lo sviluppo di applicazioni che utilizzino librerie MFC ovvero per lo sviluppo di applicazioni dotate di un interfaccia grafica utente a finestre in stile Windows Dal momento che, generalmente, per applicazioni di test non è richiesta una struttura delle applicazioni questo tipo è stato necessario apportare alcune modifiche alle opzioni di compilazione predefinite Inoltre le

173 Appendice A How to 165 librerie fornite dal DK generano conflitto con le librerie Windows Standard Per illustrare le procedure di risoluzione per questi ed altri problemi qui di seguito si riporta una serie di snapshot illustrativi dei passi da seguire 1 Creazione del progetto Per generare un progetto che non faccia uso di interfacce grafiche FILE NEW PROJECTS Win32 Console Application Dopo aver inserito il nome del progetto comparirà una finestra di Figura A3 in cui occorre selezionare la voce Empty Project per evitare l inclusione automatica da parte del compilatore di file indesiderati Per inibire l utilizzo di classi MFC: PROJECTS SETTINGS GENERAL MICROSOFT FOUNDATION CLASSES Not Using MFC Figura A3: Creazione di un progetto vuoto 2 Impostazione dei percorsi predefiniti per l inclusione di file h e lib TOOLS OPTIONS DIRECTORIES Include Files PATHdellaDIRECTORY BTWDK/Include TOOLS OPTIONS DIRECTORIES Library Files PATHdellaDIRECTORY BTWDK/Release

174 Appendice A How to 166 Figura A4: Eliminazione delle classi MFC Figura A5: Impostazione dei path predefiniti

175 Appendice A How to Inclusione dei file h e lib forniti dal DK Per garantire l inclusione degli header file e dei file lib forniti dal DK si consiglia di includere nei propri progetti il file btwlibh che conterrà le direttive seguenti: #pragma once #pragma comment(lib,"c:\\widcomm\\btw DK\\SDK\\Release\\WidcommSdklib") #include "BtIfDefinitionsh" #include "BtIfClassesh" Si noti che il path del file di libreria, pur se diverso da quello riportato nell esempio, va inserito nel formato illustrato 4 Direttive al preprocessore PROJECTS SETTINGS C/C++ PREPROCESSOR DEFINITIONS _BTWLIB Il menu a discesa deve essere posizionato alla voce General come evidenziato in Figura A6 Figura A6: Direttive al preprocessore 5 Eliminazione dei confilitti con le librerie Windows Standard ed inclusione dei file lib richiesti da Windows PROJECTS SETTINGS LINK PROJECT OPTIONS /NODEFAULTLIB:msvcrtlib PROJECTS SETTINGS LINK PROJECT OPTIONS versionlib PROJECTS SETTINGS LINK PROJECT OPTIONS ws2_32lib

176 Appendice A How to 168 Figura A7: Inclusione dei file lib 6 Impostazione della modalità di generazione del codice PROJECTS SETTINGS C/C++ USE RUN TIME LIBRARIES DEBUG MULTITHREADED DLL Il menu a discesa deve essere posizionato alla voce Code Generation come evidenziato in Figura A8 Quest impostazione è necessaria in quanto le funzioni eseguiti in thread diversi da quello contenente la main application Figura A8: Impostazione delle librerie a run time

177 Appendice A How to 169 A32 Descrizione delle API Le API messe a disposizione dallo stack BCM1000-BTW sono strutturate in classi e fanno largo uso del meccanismo della derivazione Lo stack gestisce attraverso opportune classi sia i profili sia i protocolli Bluetooth maggiormente utilizzati come schematizzato in Tabella A3 Livello OPP FTP L2CAP OBEX RFCOMM Profilo SPP LAP DUN PRINT Classe COppClient CFtpClient CL2CapIf, CL2CapConn CObexServer, CObexClient, CObexHeaders, CObexUserDefined CRfcommIf, CRfcommPort Classe CSppClient, CSppServer CLapclient CDunClient CPrintClient Classi di utilità CBtIf, CSdpService, CSdpDiscoveryReq Tabella A3: Classi per la gestione di livelli e profili Costruttori e distruttori Ogni classe è dotata di un costruttore a zero parametri e tutte le inizializzazioni delle variabili membro sono effettuate in maniera automatica L implementazione dei distruttori per la deallocazione di eventuali estensioni dinamiche introdotte nelle classi derivate è a carico del programmatore A321 Esempio di una tipica applicazione Bluetooth Per rendere immediate le modalità di utilizzo delle classi, qui di seguito si riportano gli step fondamentali per la realizzazione di una semplice applicazione e una breve descrizione delle classi utilizzate ad ogni passo Si supponga di voler realizzare un applicazione client che, dopo aver effettuato uno scanning dei dispositivi vicini, ricerca il servizio NAP per l accesso alla rete Inquiry La classe che fornisce le funzioni necessarie alla realizzazione delle operazioni di scanning e ricerca dei servizi è la classe CBtIf Essa mette a

178 Appendice A How to 170 disposizione metodi virtuali per la segnalazione degli eventi Bluetooth e la loro processazione pertanto una qualsiasi applicazione che intenda effettuare operazioni offerte dall interfaccia CBtIf deve prevedere una classe derivata in cui siano opportunamente reimplementati i metodi di interesse Il primo passo consiste allora nell istanziare un oggetto di una classe derivata dalla classe CBtIf, ad esempio //definizione della classe class BTWConnection: public CBtIf { public: BTWConnection(); }; //programma chiamante int main() { BTWConnection C; //il metodo StartInquiry non accetta parametri CStartInquiry(); return 0; } Per la memorizzazione dei dati relativi ad un dispositivo che è stato rilevato durante la procedura di scanning è opportuno reimplementare la funzione virtuale CBtIf::OnDeviceResponded() facendo in modo, ad esempio, che i dati relativi ai vari dispositivi trovati siano inseriti in una lista Il metodo CBtIf::OnDeviceResponded() è automaticamente invocata dal sistema ogni volta che viene un dispositivo viene rilevato La specifica della classe BTWConnection può essere allora modificata in questo modo: //struttura contenente le informazioni relative ai devices scoperti struct DeviceInfo { BD_ADDR bdaddress; BD_NAME bdname; DEV_CLASS cls; BOOL connected; string straddr; string strname; }; //definizione della classe class BTWConnection: public CBtIf { public:

179 Appendice A How to 171 BTWConnection(); //memorizza nella lista le informazioni relative ai dispositivi scoperti virtual void OnDeviceResponded(BD_ADDR, DEV_CLASS, BD_NAME, BOOL ); //restituisce la lista dei dispositivi scoperti list<deviceinfo>& GetDevList() const return this->devlist; private: //lista dei dispositivi scoperti list<deviceinfo> DevList; }; Ricerca dei servizi Per avviare la ricerca dei servizi, la classe CBtIf mette a disposizione il metodo CBtIf::StartDiscovery(BD_ADDR,GUID) cui vanno forniti in ingresso l indirizzo del dispositivo sui effettuare la ricerca ed il GUID del servizio I valori dei GUID sono definiti nel file bthdefh Assegnando il valore NULL al GUID la funzione riporterà tutti i servizi disponibili all indirizzo specificato int main() { BTWConnection C; //indirizzo Bluetooth su cui avviare la ricerca BD_ADDR addr =0x00,0x02,0x72,0x01,0x01,0xa9; //cerca il servizio NAP all indirizzo addr CStartDiscovery(addr, CBtIf::guid_SERVCLASS_NAP); return 0; } I servizi trovati tramite il metodo CBtIf::StartDiscovery(BD ADDR,GUID) vengono memorizzati all interno di un database dei servizi gestito in maniera cumulativa ovvero in modo tale da contenere i servizi scoperti da tutte le applicazioni che hanno invocato la funzione, e tenendo i risultati in cache per tutto in cui il dispositivo continua ad essere rilevato mediante inquiry Quando la ricerca dei servizi è stata completata, viene automaticamente invocato il metodo CBtIf::OnDiscoveryComplete() che va eventualmente reimplementato Per accedere ai risultati della ricerca è necessario invocare la funzione CBtIf::ReadDiscoveryRecords(BD ADDR,int,CSdpDiscoveryRec,GUID)

180 Appendice A How to 172 che restituisce i record relativi ai servizi trovati in un oggetto di classe CSdpDiscoveryRec Una possibile implementazione della classe BTWConnection diventa allora la seguente: //definizione della classe class BTWConnection: public CBtIf { public: BTWConnection(); //provvede a memorizzare le informazioni relative ai dispositivi scoperti virtual void OnDeviceResponded(BD_ADDR, DEV_CLASS, BD_NAME, BOOL ); //invoca la funzione ReadDiscoveryRcords() e memorizza i risultati virtual void OnDiscoveryComplete(); list<deviceinfo>& GetDevList() const return this->devlist; private: list<deviceinfo> DevList; //array di oggetti CSdpDiscoveryRec CSdpDiscoveryRec SDPlist [MAXSDPLISTSIZE]; }; Inquiry e successiva ricerca dei servizi Nel caso in cui non sia noto l indirizzo del dispositivo su cui cercare un determinato servizio, è possibile provare a cercarlo su tutti i dispositivi rilevati durante la procedura di inquiry Una possibile implementazione per la risoluzione del problema è la seguente: int main() { BTWConnection C; CStartInquiry(); list<deviceinfo> lista; lista=cgetdevlist(); list<deviceinfo>::const_iterator iter; ricerca il servizio NAP su tutti i dispositivi rilevati) for(iter=listabegin();iter!=listaend();iter++) CStartDiscovery(iter->bdaddress, CBtIf::guid_SERVCLASS_NAP); return 0; } A322 Problemi di sincronizzazione: il meccanismo degli eventi di Windows Per gestire in maniera efficiente il meccanismo della chiamata automatica delle funzioni del tipo CBtIf::OnDeviceResponded() si consiglia l utilizzo delle funzioni per la sincronizzazione degli eventi messe a disposizione da Windows Si consideri il seguente frammento di codice, in cui la funzione

181 Appendice A How to 173 Scan() implementa tutte le operazioni descritte al Paragrafo precedente per l operazione di inquiry int main() { BTWConnection C; CScan(); loggerwriteinfo("main:scan operations completed"); /*altre istruzioni*/ {} list<deviceinfo> lista; lista=cgetdevlist(); //ricerca il servizio NAP su tutti i dispositivi rilevati) for(iter=listabegin();iter!=listaend();iter++) CStartDiscovery(iter->bdaddress, CBtIf::guid_SERVCLASS_NAP); return 0; } Affinché il programma chiamante resti in attesa che le operazioni di scanning siano completate e non continui la sua esecuzione è necessario bloccarlo su un oggetto che la funzione Scan() ha la responsabilità di sbloccare prima della sua terminazione Il frammento di codice seguente illustra una possibile soluzione del problema: //definizione della classe class BTWConnection: public CBtIf { public: BTWConnection(); //memorizza nella lista le informazioni relative ai dispositivi scoperti virtual void OnDeviceResponded(BD_ADDR, DEV_CLASS, BD_NAME, BOOL ); //viene invocata al termine delle operazioni di scanning virtual void OnInquiryComplete(BOOL,short ); //restituisce la lista dei dispositivi scoperti list<deviceinfo>& GetDevList() const return this->devlist; HANDLE event; private: //lista dei dispositivi scoperti list<deviceinfo> DevList; }; //funzioni membro della classe BTWConnection void BtwConnection::Scan() throw (Exception){ BOOL suc; suc=startinquiry(); this->event=createevent(null,false,false,null))==null } void BtwConnection::OnDeviceResponded(BD_ADDR addr, DEV_CLASS cls, BD_NAME name, BOOL con) DeviceInfo *device=new DeviceInfo; {

182 Appendice A How to 174 } DevListpush_front(*device); void BtwConnection::OnInquiryComplete (BOOL success, short num_responses) SetEvent(this->event) //programma chiamante int main() { BTWConnection C; CScan(); //si blocca in attesa che l evento si sblocchi WaitForSingleObject(Cevent,INFINITE); //riprende l esecuzione loggerwriteinfo("main:scan operations completed"); /*altre istruzioni*/ {} list<deviceinfo> lista; lista=cgetdevlist(); //ricerca il servizio NAP su tutti i dispositivi rilevati) for(iter=listabegin();iter!=listaend();iter++) CStartDiscovery(iter->bdaddress, CBtIf::guid_SERVCLASS_NAP); return 0; } Ulteriori dettagli sull utilizzo dei meccanismi di sincronizzazione di eventi, processi e thread nel sistema operativo Windows sono disponibili all URL: /en-us/dllproc/base/waitforsingleobjectasp

183 Appendice B Bluetooth B1 Introduzione Lo spirito con cui nasce Bluetooth è simpaticamente racchiuso nel significato del suo nome: così come Harald Bltand (Harold Bluetooth in inglese), Re di Danimarca e di Norvegia, nel 940 riuscì a unificare le tribù della Danimarca, Norvegia e Svezia, così la nuova tecnologia si proponeva, nel 1994, la formulazione di uno standard di comunicazione che unificasse -rendendoli interoperabilidispositivi mobili di diversa natura e provenienza Le caratteristiche chiave che hanno sancito l enorme successo della tecnologia Bluetooth sono senz altro la robustezza, la bassa complessità, e i costi contenuti B2 Lo stack Bluetooth Bluetooth è strutturata secondo un architettura a livelli in cui i protocolli di più basso livello fungono da provider di servizi per i protocolli soprastanti; lo stack ha l aspetto di Figura B1 B203 Livello radio Il livello radio di Bluetooth, equivalente allo strato fisico dell architettura OSI, lavora nella banda ISM a 24GHz e riduce l interferenza prodotta da segnali estranei cambiando frequenza dopo avere trasmesso o ricevuto ogni 175