Bluetooth for Programmers | Cerca per titolo, autore, parola chiave | ||||||||
Bluetooth for Programmers Albert Huang, Larry Rudolph, 2005. Per dirla con una sola frase, Bluetooth è una tecnica che permette alle periferiche di comunicare fra loro, su brevi distanze, senza bisogno di cavi. Ogni chip Bluetooth prodotto nel mondo riporta stampato un suo indirizzo a 48 bit, globalmente univoco, che identifica inequivocabilmente una, ed una sola, periferica. È un indirizzo assimilabile al MAC address del protocollo Ethernet, tant'è che entrambi gli spazi degli indirizzi sono gestiti dalla stessa organizzazione: la IEEE (Institute of Electrical and Electronics Engineers) Registration Authority. Questi indirizzi vengono assegnati, alla singola periferica, al momento della produzione: sono unici e tali restano per l'intera vita del chip a cui sono stati assegnati. Questi indirizzi sono l'unità di base di indirizzamento di tutta la programmazione Bluetooth. Affinché una periferica Bluetooth possa comunicare con un'altra periferica, deve, in qualche modo, determinarne l'indirizzo Bluetooth. Questo indirizzo viene usato a tutti i livelli di Bluetooth, dai livelli più bassi, i protocolli radio, ai livelli più alti, i protocolli delle applicazioni (a differenza di quello che accade con le reti TCP/IP, che a livello Ethernet utilizzano il 48-bit MAC address, mentre ai livelli più alti utilizzano l'indirizzo IP). In Bluetooth, il solo modo in cui una periferica può conoscere l'indirizzo di un'altra periferica, è interrogare tutte le periferiche Bluetooth che si trovano nel suo raggio d'azione (a differenza di quello che accade con le reti IP, dove l'interrogazione viene fatta al Domain Name System, o DNS). Una volta ottenuto l'indirizzo della periferica alla quale desidera connettersi, l'applicazione client dovrà scegliere quale protocollo di trasporto usare. In internet, i protocolli di trasporto più usati sono TCP/IP e UDP, che, a loro volta, si affideranno al sottostante protocollo IP per il trasporto definitivo. TCP offre un metodo di trasporto orientato alla connessione (connection-oriented), che si preoccupa di garantire la massima affidabilità nell'invio dei dati, mentre UDP cerca di garantire la massima velocità del trasporto, anche a scapito dell'affidabilità, inviando datagramma (pacchetti di dati) di lunghezza fissa, limitando la quantità di dati da aggiungere al successivo pacchetto IP. In Bluetooth, abbiamo:
Viste queste premesse, si può affermare che un programmatore userà RFCOMM nelle situazioni in cui sceglierebbe TCP, mentre userà L2CAP nelle situazioni in cui sceglierebbe UDP. Port numbers Una volta che abbiamo l'indirizzo della periferica alla quale connetterci e un protocollo a cui appoggiarci, non ci resta che scegliere un numero di porta. Praticamente tutti i protocolli di trasporto Internet usano la nozione di numero di porta, nozione che permette a più applicazioni in esecuzione sullo stesso computer di utilizzare simultaneamente un protocollo di trasporto. Bluetooth non fa eccezione, anche se utilizza una differente terminologia. In L2CAP, le porte sono chiamate Protocol Service Multiplexers (PSM), che possono assumere un valore dispari compreso tra 1 e 32767 (non chiedetevi il perché, sarebbe inutile!). In RFCOMM, ci sono 30 canali (channels). Differenze a parte, entrambi, protocol service multiplexers e channels svolgono lo stesso ruolo svolto dalle porte TCP/IP. L2CAP, a differenza di RFCOMM, ha una serie di porte riservate, non utilizzabili ne dai protocolli, ne dalle applicazioni utente: dalla 1 alla 1023. Nella programmazione Internet, le applicazioni server fanno tradizionalmente uso dei cosiddetti well known port numbers (numeri di porta ben noti) che vengono scelti ed approvati in fase di progettazione. Le applicazioni client utilizzeranno lo stesso numero di porta ben noto, per connettersi al server. Il principale svantaggio di questo approccio è che due applicazioni server non potranno utilizzare lo stesso numero di porta. Data la relativa giovinezza di TCP/IP e il gran numero di numeri di porta a disposizione, questo non è mai stato un problema serio. I protocolli di trasporto Bluetooth, come abbiamo visto, hanno meno numeri di porta a disposizione, riducendo così la possibilità di scegliere un numero di porta arbitrario in fase di progettazione. Sebbene questo non sia un problema significativo per L2CAP, che può contare su circa 15.000 numeri di porta non riservati, RFCOMM conta solo 30 differenti numeri di porta. Una conseguenza di ciò è che c'è una possibilità superiore al 50% di collisione di numeri di porta con solo 7 applicazioni server. In questo caso, quindi, il progettista non potrà scegliere arbitrariamente i numeri di porta. La risposta Bluetooth a questo problema è il Service Discovery Protocol (SDP). Invece di concordare un numero di porta in fase di progettazione, l'approccio Bluetooth è di assegnare i numeri di porta in fase di esecuzione (runtime), seguendo un modello di sottoscrizione pubblica (publish-subscribe). Il computer host esegue un'applicazione server, chiamata SDP server, che usa una delle poche porte riservate L2CAP. Le altre applicazioni server si vedono assegnare dinamicamente i numeri di porta in fase di esecuzione (runtime) e registrano una descrizione di se stesse e il servizio che offrono (insieme ai numeri di porta a loro assegnati) con il server SDP. Le applicazioni client, a questo punto, interrogano il server SDP installato in una particolare macchina per ottenere le informazioni di cui hanno bisogno. Questo solleva una questione: come fa un client a sapere quale descrizione coincide con il servizio che sta cercando? La risposta più immediata è stata di assegnare ad ogni singolo servizio un unico codice identificativo. La Internet Engineering Task Force ha sviluppato un metodo standard per gli sviluppatori software per generare indipendentemente il loro Universally Unique Identifiers (UUID) a 128-bit. Questa è l'idea di base intorno alla quale ruota SDP, in cui l'identificativo è chiamato il Service ID del servizio. Lo sviluppatore sceglie lo UUID al momento dello sviluppo software e, quando il software verrà eseguito, dovrà registrare il suo Service ID nel server SDP. Un'applicazione client che cerchi uno specifico servizio, dovrà interrogare il server SDP di ciascuna periferica raggiungibile per sapere se la periferica offre un servizio che abbia quello stesso UUID. Gli UUID hanno la forma seguente: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX dove ciascuna 'X' è una cifra esadecimale. Quindi, il primo segmento di 8 cifre esadecimali corrisponde ai bit 1-32 dello UUID, mentre il segmento seguente di 4 cifre esadecimali è composto dai bit 33-36, e così via. Poiché il Service ID può comportare tempi lunghi per l'identificazione del servizio che stiamo cercando, possiamo considerarlo un ottimo strumento per applicazioni personalizzate, create da un singolo gruppo di sviluppatori. Nell'architettura Bluetooth, era importante distinguere queste applicazioni "customizzate" dalle classi di applicazioni, ciascuna delle quali esegue lo stesso compito. Per esempio, due differenti compagnie possono realizzare applicazioni che offrono servizi audio su Bluetooth. Nonostante si tratti di programmi differenti, scritti da differenti programmatori, essi svolgono lo stesso compito. Per gestire questa differenziazione, Bluetooth ha introdotto un secondo UUID, il Service Class ID. Ora, i due differenti programmi potranno rendere pubblico lo stesso Service Class ID. Non solo: nel caso di un'applicazione che fosse in grado di offrire più servizi (per esempio, un paio di cuffie Bluetooth potrebbe anche essere in grado di rispondere ad una chiamata telefonica, o silenziare un microfono, terminare una chiamata, e così via), è possibile dichiarare, per una singola applicazione, un elenco di Service Class ID offerti. Così, un singolo servizio può avere un solo Service ID e più Service Class ID. Abbiamo appena descritto SDP come un modo per conoscere la porta e il protocollo utilizzati da un determinato servizio, utilizzando un Service ID o un Service Class ID come chiave di ricerca. Un modo più generale di pensare a SDP è di considerarlo un vero e proprio database. Ogni record di questo database è, in realtà, un elenco di attributi (list of attributes), in cui ogni singolo attributo è composto dalla coppia: ID, value Lo ID è un numero intero senza segno a 16-bit (unsigned integer), che specifica il tipo di attributo, mentre i dati reali dell'attributo sono descritti nel campo value. Un'applicazione client, in cerca di un servizio, può cercare tra tutti questi attributi, anche se la gran parte cercherà tra i due attributi appena menzionati. Il dato contenuto nel campo value può essere uno UUID, un numero intero, un valore booleano (boolean value), una stringa di testo, una lista di uno di questi tipi di dato, una lista di liste. I valori possono avere qualsiasi dimensione, fino a 4 GB. Bluetooth definisce alcuni ID di attributo riservati, che hanno un significato speciale, mentre tutti gli altri ID possono essere usati a discrezione dei programmatori. I più comuni attributi riservati sono:
Fin qui, abbiamo visto come evitare i problemi legati alla scelta di numeri fissi di porta e come un'applicazione può usare SDP per trovare uno specifico servizio. È bene ricordare, però, che non è obbligatorio rivolgersi a SDP per assegnare i numeri di porta: è anche possibile tornare allo schema TCP/IP di assegnazione dei numeri di porta al momento della programmazione, nella speranza di evitare conflitti e questo porterebbe anche qualche beneficio in termini di tempi. In ambienti controllati o in progetti in-house, questo potrebbe avere un senso. Tuttavia, per creare applicazioni portabili, che verranno eseguite in un gran numero di scenari, si dovrebbe usare il sistema di assegnazione dinamico delle porte e SDP. Sockets Scegliere la macchina alla quale connettersi e decidere come connettersi ad essa è la parte più complicata, nella programmazione Bluetooth. Una volta scelti il protocollo di trasporto e il numero di porta, il resto delle comunicazioni Bluetooth è essenzialmente simile, nella programmazione, a ciò a cui i programmatori di rete sono abituati: i socket! Un'applicazione server in attesa di una connessione Bluetooth in entrata è concettualmente uguale ad un'applicazione server in attesa di una connessione Internet in arrivo. Un'applicazione client che tenta di stabilire una connessione con un server esterno si comporta sempre nello stesso modo, che si tratti di usare RFCOMM, oppure L2CAP, oppure TCP, oppure UDP. Un socket, nella programmazione di rete, rappresenta l'estremità di un collegamento (un socket, infatti, è una presa elettrica). L'idea di fondo è che, dal punto di vista di un'applicazione software, tutti i dati che devono passare attraverso un collegamento devono entrare oppure uscire dal socket. Introdotti nei sistemi operativi 4.2 BSD (Berkeley Software Distribution), i socket sono diventati lo standard de-facto per la programmazione di rete. Per instaurare una connessione Bluetooth, un programma deve, innanzitutto, creare un socket, che servirà da punto di arrivo (o punto di partenza) della connessione. I socket sono usati per tutti i tipi di rete: la prima cosa da fare, quindi, è specificare quale tipo di socket si sta creando, così da utilizzare il protocollo corretto per i dati da inviare. Nella programmazione Bluetooth, i socket sono quasi sempre socket L2CAP o RFCOMM. Appena creato, il socket non è connesso e non può ancora essere utilizzato per le comunicazioni. Per aprire una connessione, è necessario, prima, stabilire se il socket verrà utilizzato come server, in ascolto per intercettare connessioni in arrivo, oppure come client, in procinto di stabilire una connessione con un server esterno:
Una delle maggiori differenze tra un server socket ed un client socket è che il server socket, creato dall'applicazione, non potrà mai essere usato per una comunicazione reale. Infatti, ogni volta in cui il server socket accetterà una nuova connessione in ingresso, verrà generato un nuovo socket, che rappresenterà la nuova connessione. Il server socket, quindi, tornerà in ascolto di nuove richieste di connessione, mentre l'applicazione potrà utilizzare il socket appena creato, per comunicare con il client. Comunicare, utilizzando i comandi: send receive per inviare e ricevere dati. Una volta finito lo scambio di dati, l'applicazione potrà invocare il comando: close per disconnettere il socket. Chiudere il socket di un server in ascolto (listening server) comporterà l'unbind della porta e lo stop alla accettazione delle connessioni in arrivo. Useful things to know about Bluetooth Gli adapter Bluetooth vengono divisi in tre classi di potenza:
La gran parte delle apparecchiature per il consumatore, cellulari, cuffie audio, laptop, sono di classe 2. È la classe più alta che determina la reale potenza: se una periferica USB di classe 1 comunica con un cellulare di classe 2, il raggio di azione e la potenza della comunicazione saranno limitate dal cellulare. La Classe 3 è molto rara, nel mondo reale. Naturalmente, l'assenza di ostacoli tra le due periferiche può aumentarne il raggio di azione, mentre la presenza di oggetti o di interferenze radio può diminuirlo. Il corpo umano stesso, costituito per il 60% di acqua, tende ad assorbire i segnali radio alle frequenze usate da Bluetooth. La distanza è correlata esclusivamente alla potenza di trasmissione. Distanze maggiori di quelle dichiarate comportano un maggior numero di errori nella trasmissione. È anche difficile dare una stima affidabile della larghezza di banda di un canale di comunicazione Bluetooth. Teoricamente, due periferiche Bluetooth hanno un data rate asimmetrico massimo (solo una delle due periferiche sta trasmettendo) di 723,2 kilobit per second (kb/s) e un data rate simmetrico massimo (entrambe le periferiche stanno trasmettendo dati vicendevolmente) di 433,9 kb/s. In realtà, il transfer rate che probabilmente vedrete sarà sempre un pochino inferiore, visto che nelle comunicazioni wireless c'è sempre un po' di rumore che disturba il canale. Le periferiche conformi alle specifiche Bluetooth 2.0, anno 2004, hanno un limite massimo teorico tre volte superiore: 2178.1 kb/s asimmetrico, 1306.9 kb/s simmetrico. Le periferiche Bluetooth operano nella banda di frequenza di 2.4 GHz. Questo significa che Bluetooth usa le stesse frequenze radio dei forni a microonde, 802.11, e dei telefoni senza fili (cordless). Ciò che distingue Bluetooth dalle altre tecnologie è che Bluetooth divide la banda in 79 canali ed utilizza la tecnica definita channel hopping, che consiste nel cambiare continuamente la frequenza di trasmissione. Le tecnologie wireless 802.11b e 802.11g dividono la banda di 2.4 GHz in 14 canali, larghi 5 MHz ciascuno. Quando una rete wireless viene impostata, l'amministratore di rete sceglie uno di quei canali e tutte le periferiche 802.11 presenti su quella rete wireless trasmetterà sempre sulla frequenza radio assegnata a quel canale. Se, nella stessa area, esistono altre reti wireless, come in un condominio, dove in ogni appartamento esiste un router wireless, ci saranno buone possibilità che alcune di queste reti si sovrappongano l'una con l'altra, generando una sofferenza nelle prestazioni. Anche Bluetooth, come 802.11, divide la banda di 2.4 GHz in canali, ma i canali Bluetooth sono 79, e non 14, ed hanno una dimensione di 1 MHz, e non 5 MHz. Ma, soprattutto, le periferiche Bluetooth non trasmettono sempre sullo stesso canale. Una periferica Bluetooth che sta trasmettendo dati cambia canale di trasmissione ogni 625 microsecondi (1600 volte al secondo), in ordine il più possibile casuale, nel tentativo di evitare che un solo canale venga usato molto di più di qualsiasi altro canale. Naturalmente, due periferiche Bluetooth che stanno comunicando l'una con l'altra devono saltare da un canale all'altro insieme, così da garantire di trasmettere e ricevere dati sulle stesse frequenze. Questa tecnica, chiamata frequency hopping, fa di Bluetooth una tecnologia molto più robusta rispetto alle interferenze da altre fonti di onde radio, permettendo anche la coesistenza, nella stessa area, di più reti Bluetooth. Le versioni più recenti di Bluetooth (1.2 e oltre) fanno ancora meglio, utilizzando una tecnica chiamata adaptive frequency hopping, che permette alle periferiche di evitare i canali di trasmissione con più rumore e interferenze (per esempio, un canale che coincide con una rete 802.11 nelle vicinanze). Si può discutere su quanto tutto questo aiuti, ma certamente tutto questo rende Bluetooth una tecnologia molto più complicata di altre tecnologie di rete wireless. Due o più periferiche Bluetooth che stanno comunicando l'una con l'altra, utilizzando la stessa configurazione di channel hopping (così da utilizzare sempre le stesse frequenze), formano una Bluetooth piconet. Una piconet può essere composta da massimo 8 periferiche totali. Come fanno le 8 periferiche ad accordarsi su quali frequenze utilizzare e quando utilizzarle? Ecco che qui entra in gioco il master. In ogni piconet, una periferica assume il ruolo di master. La periferica master svolge due compiti:
L'ultimo aspetto da conoscere delle reti Bluetooth è la cosiddetta scatternet. Per una singola apparecchiatura (periferica) Bluetooth, è possibile partecipare a più di una singola piconet. Quando ciò accade, le due differenti piconet vengono chiamate collettivamente scatternet. A dispetto del nome altisonante, le scatternet non fanno assolutamente nulla. Affinché due periferiche possano comunicare l'una con l'altra, devono appartenere alla stessa piconet. Essere parte di una stessa scatternet, insomma, non aiuta in alcun modo e la periferica che partecipa alle due piconet non ha alcuna capacità addizionale di routing. Scatternet è solo un nome, niente di più. Per essere chiari, da un punto di vista del programmatore, piconet, scatternet, master, slave sono solo concetti, poiché il tutto è gestito direttamente e automaticamente dall'hardware Bluetooth e dai driver di basso livello. Come sviluppatore, uno deve solo impostare una connessione tra due periferiche Bluetooth. Bluetooth Profiles Oltre ai protocolli di trasporto TCP, IP, UDP, in internet esistono molti altri protocolli che specificano come effettuare determinate operazioni, quali, per esempio, instradare i pacchetti di dati, inviare email, trasferire file, caricare pagine web. Una volta standardizzati dalla Internet Engineering Task Force, sotto forma di Request For Comments (RFC), questi protocolli vengono generalmente adottati dall'intera comunità internet. Anche Bluetooth ha una sua procedura per proporre, ratificare, standardizzare protocolli e specifiche tecniche. L'equivalente Bluetooth di una RFC è il Bluetooth Profile. Esiste un profilo per scambiare informazioni di geolocalizzazione (Local Positioning Profile), oppure per stampare utilizzando le stampanti vicine (Basic Printing Profile), oppure per effettuare chiamate utilizzando il modem più vicino (Dial Up Networking Profile). Esiste anche un profilo per incapsulare il traffico TCP/IP in una connessione Bluetooth, così da ridurre la programmazione Bluetooth alla semplice programmazione Internet.
|
|||||||||
Bluetooth for Programmers | Disclaimer: questo è un link a contenuti ospitati su server esterni. |