relazione

Università degli Studi di Bologna
Facoltà di I ng egneria
A.A. 2006/2007
di Nicola Bonoli
(Matricola 0000196199)
Giugno 2007
Abstract. La recente affermazione e diffusione della tecnologia Bluetooth nei
dispositivi di nuova generazione come telefoni cellulari, smartphone, palmari,
computer portatili e fotocamere digitali, ha aperto un nuovo scenario : il Proximity
Marketing.
Sfruttando la tecnologia Bluetooth è infatti possibili distribuire, ai dispositivi
consenzienti, contenuti di svariato genere e formato, senza dover sostenere un costo
relativo ad ogni invio.
BlueMark realizza tale servizio con un occhio di riguardo ad aspetti quali privacy,
spamming, QoS ed availability.
Introduzione
BlueMark è un sistema in grado di distribuire contenuti multimediali verso telefoni cellulari abilitati
alla ricezione Bluetooth®.
Può essere utilizzato per promuovere informazioni su prodotti e offerte commerciali oppure
distribuire servizi, notizie e informazioni utili.
L’area di copertura del sistema è influenzata dalla locazione del trasmettitore Bluetooth e una
maggiore copertura può essere garantita, ad oggi, attraverso una opportuna disposizione di più
trasmettitori.
Tale scenario apre nuovi problemi dovuti alla coordinazione di questi dispositivi in modo tale da
evitare fenomeni di “spamming” via Bluetooth.
E’ opportuno infatti che il possessore del dispositivo Bluetooth non sia ulteriormente disturbato da
successive richieste di trasferimento di contenuti in seguito ad una precedente ricezione o rifiuto.
Ciò deve verificarsi indipendentemente dalla propria posizione e, di conseguenza, dal trasmettitore
Bluetooth coinvolto.
Al tempo stesso deve essere possibile garantire la fornitura del servizio anche a fronte di guasti
hardware permettendo a più trasmettitori di agire nella stessa area di copertura.
Analisi dei Requisiti
Dispositivi Client
Non sono altro che i dispositivi dotati di tecnologia Bluetooth in stato “rilevabile”. Il possessore del
dispositivo dovrà ricevere un avviso di invio del contenuto e, nel caso lo voglia ricevere, dovrà
acconsentire all’invio. Nel caso non desideri ricevere il contenuto sarà sufficiente rifiutare e non sarà
più disturbato.
BlueMark Server
E’ incaricato di recuperare e fornire i contenuti richiesti dai BlueMark Proxy destinati ai dispositivi
Client. Deve essere in grado di gestire richieste concorrenti per poter fornire il servizio a più
BlueMark Proxy garantendo quindi la scalabilità del sistema. Non è esplicitamente richiesta
availability lato Server.
BlueMark Proxy
E’ incaricato di effettuare il discovery dei dispositivi Client, verificare lo stato di tali dispositivi e
gestire, secondo le politiche impostate, la trasmissione dei contenuti in modo da evitare il cosiddetto
fenomeno del “blueSpam”.
Tutto ciò avendo come obiettivo quello di consegnare il contenuto nel minor tempo possibile ed al
maggior numero di dispositivi rilevati. I contenuti possono essere di diverso tipo: immagini GIF o
JPEG, file audio MP3 o applicazioni Java (file JAR).
Deve garantire il rispetto della privacy utilizzando informazioni impersonali (come il device UUID)
per l’identificazione e la gestione del dispositivo.
Deve inoltre coordinarsi con gli altri BlueMark Proxy in modo da rispettare le politiche di
trasmissione.
Deve essere in grado di garantire la continuità del servizio ripristinando, velocemente, il
funzionamento corretto a fronte di un guasto singolo, garantendo quindi nel sistema l’assenza di punti
critici di singolarità.
Il progetto del Proxy dovrà inoltre tenere presenti aspetti come l’identificazione dei colli di bottiglia e
considerare la gestione delle risorse. Dovrà essere progettato nell’ottica di permettere, attraverso
estensioni future, il soddisfacimento di vincoli relativi alla QoS come, ad esempio, priorità tra i
dispositivi client, tailoring, sicurezza.
Macroscelte progettuali
In fase di progetto sono state effettuate svariate scelte che verranno, di seguito, commentate trattando
in primo luogo le scelte relative a BlueMark Server ed, in seguito quelle relative al BlueMark Proxy.
Per entrambi si è scelto il linguaggio di programmazione Java. La trasparenza dal sistema operativo
non è garantita lato Proxy a causa della stretta relazione tra il sistema operativo e lo stack Bluetooth.
BlueMark Server
Interazioni con i Proxy: la scelta di CORBA
La scelta di Corba per le interazioni tra Proxy e Server nasce da tre motivazioni principali:
integrazione, eterogeneità e concorrenza.
Corba permette infatti di operare su una infrastruttura per l’interazione tra ambienti eterogenei e
fornisce funzioni di conversione in formato generico e un protocollo di interazione comune.
Ciò garantisce a livello Server trasparenza del sistema operativo e dei protocolli di rete, trasparenza
del linguaggio di programmazione, trasparenza della posizione.
Inoltre, guardando ad eventuali sviluppi futuri di BlueMark, garantisce trasparenza alla replicazione
del Server e facile gestione della tolleranza ai guasti lato Server garantendo facilmente il requisito di
availability lato Server.
Corba fornisce inoltre il supporto per la gestione di richieste concorrenti sgravando il programmatore
da tale compito e controbilanciando lo sforzo implementativo di una interazione tramite Corba
rispetto alla più semplice implementazione tramite RMI.
La scelta di Corba, ed in particolare dell’ORB di Java (ordb), è sembrata quindi la più appropriata.
BlueMark Proxy
Proxy e Bluetooth: BlueCove e Avetana OBEX
Lo stack protocollare Bluetooth è il software che ha accesso diretto ai dispositivi Bluetooth mentre
profili Bluetooth descrivono l’interoperabilità tra le piattaforme e i requisiti di consistenza e
permettono quindi la comunicazione tra dispositivi eterogenei dotati di tecnologia Bluetooth.
Per lo scambio di dati esistono due profili: RFCOMM e OBEX Push.
RFCOMM è più indicato per trasferire stream di dati esattamente come si farebbe con una porta
seriale. OBEX è invece indicato quando i dati da scambiare sono file, insieme alle informazioni
associate come il tipo di file, la data e la dimensione.
Risulta ovvia quindi la scelta di OBEX per il trasferimento dei contenuti dal Proxy ai dispositivi.
Microsoft ha integrato nativamente il supporto a Bluetooth nella versione XP SP2 mentre in ambiente
Java le API JSR-82 rappresentano l’ambiente di sviluppo ufficiale per la tecnologia Bluetooth.
BlueCove è una implementazione Java delle API JSR-82 che si interfaccia con lo stack Bluetooth
Microsoft. Originariamente è stata sviluppata dalla Intel ed è attualmente gratuita e curata da
volontari.
Poiché lo stack Bluetooth Microsoft supporta esclusivamente connessioni RFCOMM anche
BlueCove supporta solo queste. E’ possibile ottenere il sevizio di OBEX Push attraverso l’utilizzo
dell’implementazione opensource AvetanaOBEX.
Gestione della persistenza: database MySQL
La persistenza si rende indispensabile per tenere traccia dello stato dei dispositivi Client coinvolti ed
implementare i meccanismi che rispettino le politiche del sistema.
A tal fine sarebbe stato sufficiente utilizzare dei semplici file testuali o strutture dati dinamiche come
array o vector. Tali soluzioni sono state scartate a favore dell’utilizzo di un database relazionale che
permette non solo di ottenere una maggiore persistenza rispetto alle strutture dati dinamiche ma anche
una notevole facilità e velocità di manipolazione tramite le query SQL.
Inoltre permette di separare facilmente, nel caso fosse necessario, il nodo Proxy dal Database Server,
con una semplicissima configurazione tramite il file di testo di configurazione del Proxy.
La scelta di MySQL deriva dal notevole vantaggio di sgravarsi da eventuali oneri derivanti
dall’acquisto di un database commerciale.
Availability: replicazione decentralizzata e Token Ring
Il requisito fondamentale della availability impone di scartare soluzioni centralizzate come, ad
esempio, quella di mantenere lo stato dei dispositivi client sul Server. Si è optato pertanto per una
soluzione che evitasse al massimo i punti critici associando ad ogni Proxy un database e coordinando
i Proxy tramite token ring. La comunicazione tra i Proxy avviene tramite scambio di messaggi e alla
semantica di ciascuno di essi sono associate determinate operazioni sul nodo che li riceve.
Attraverso la configurazione ad anello logico tutti i Proxy possono quindi comunicare ed aggiornare
la propria copia locale e, al ricevimento di un particolare messaggio, denominato BMTOKEN,
potranno avviare la proceduta di richiesta di invio ai dispositivi.
La scelta della token ring deriva inoltre dalla possibilità di gestire la caduta di un nodo attraverso una
opportuna procedura di recovery e, al tempo stesso, consente di ridurre il numero di connessioni fra
Proxy rispetto ad una soluzione con configurazione a stella.
Availability: comunicazione tramite socket TCP
La scelta delle socket TCP è legata ai requisiti di availability e QoS.
Infatti garantiscono trasferimenti di byte affidabili ed ordinati e permettono altresì di rilevare la
caduta del nodo precedente o del nodo successivo nell’anello semplicemente attraverso la gestione
delle eccezioni generate da eventuali errori di connessione. Esse sono quindi determinanti per l’avvio
della procedura di recovery senza dover gestire un clock globale che, soprattutto in ambito distribuito,
è di difficile implementazione.
Load Balancing: considerazioni e Thread Pool
Pur non essendo richiesto, il bilanciamento del carico potrebbe essere un requisito del sistema in
particolare nel caso in cui più BlueMark Proxy operino nella stessa area di copertura. Il sistema è
stato progettato in modo da poter facilmente implementare una politica di bilanciamento del carico
semplicemente limitando il numero di invii per ogni proxy. L’attuale implementazione tuttavia non ha
un limite complessivo sugli invii poiché mira a raggiungere il maggior numero di dispositivi trovati
trascurando gli aspetti di bilanciamento del carico. Per evitare tuttavia di sovraccaricare il singolo
nodo con eccessivi cambi di contesto nonché congestionare il traffico in uscita dal dispositivo
bluetooth è stato implementato un Thread Pool (di capacità limitata a 5 thread per proxy) nel quale
ogni thread è incaricato dell’invio del contenuto al dispositivo.
Architettura Finale
Alla luce delle scelte progettuali appena trattate si è delineata una architettura complessiva del
sistema BlueMark schematizzata dalla seguente figura:
BlueMark Server
L’implementazione del BlueMark Server è costituita da 4 package:
Package BMServerDatabase
Realizza la funzione di accesso al database lato Server, utilizzato per organizzare i contenuti messi a
disposizione dei Proxy e recuperarne i riferimenti locali. Il database di del Server associa ad ogni
contenuto una tabella.
In base al tipo di dispositivo (DeviceId)
può essere impostato un differente
contenuto in termini di nome del file di
destinazione e di tipo di file. Viene inoltre
specificato il percorso locale al Server per
recuperare il file associato.
Il campo ‘ContentType’ permette di
specificare se il contenuto è di tipo statico
o dinamico.
Nel caso sia dinamico il file specificato
potrebbe essere semplicemente il file di
origine dal quale il Server potrebbe creare
ed inviare il file da trasmettere finale.
La seguente figura mostra il contenuto della tabella associata al contenuto avente identificativo ‘1’.
Questo contenuto è stato utilizzato in fase di test del sistema BlueMark.
Package CORBAFileDownload
E’ l’implementazione del servizio di download del file lato Server. Tramite il riferimento all’oggetto
remoto il Proxy può infatti recuperare il file, ottenere il nome del file ed il tipo di file in modo da
portare a termine correttamente il trasferimento verso i dispositivi.
La specifica IDL del servizio è quindi la seguente (FileInterface.idl):
interface FileInterface
{
typedef sequence<octet> Data;
Data downloadFile(in string ID,in string DeviceType);
string getFileName(in string ID);
string getFileType(in string ID);
};
Come si può notare il metodo downloadFile riceve come argomento, oltre all’identificativo univoco
del contenuto, anche una specifica del tipo di dispositivo destinatario del contenuto in modo da poter
gestire un eventuale tailoring dei contenuti.
Package RemoteDevices
Contiene una interfaccia nella quale sono specificate costanti relative ai tipi di dispositivo.
Ovviamente tale package è previsto in funzione di estensioni future del Server.
Package Utilities
Contiene due classi utili alla configurazione
del Server. In particolare la classe
NodeStructure.java rappresenta un generico
nodo in termini di identificativo univoco,
indirizzo IP e porta.
La classe
ServerStructure.java riceve tramite file di
testo i parametri di configurazione del
Server permettendo di assegnare un
identificativo al Server stesso (riga 1), un
riferimento al Naming Service Corba (riga
2) e al database Server (riga 3).
BlueMark Proxy
La figura seguente schematizza la struttura del Proxy a livello di package. Le interazioni tra i thread
costituenti il Proxy avvengono attraverso i meccanismi di sincronizzazione e verranno dettagliate
durante l’analisi dei singoli package.
Package Remote Devices, Utilities e ThreadPool
Sono in parte già stati descritti nell’analisi del BlueMark Server. Il package utilities contiene la classe
StringUtils.java utilizzata per manipolazione di stringhe e la classe ProxyStructure.java che, a partire
da un file di configurazione testuale determina i parametri di configurazione del Proxy.
In particolare vengono impostati (in ordine di riga):
1.
Identificativo, IP e porta di ascolto del nodo stesso
2.
Identificativo, IP e porta di ascolto del nodo precedente nel ring logico
3.
Identificativo, IP e porta di ascolto del nodo successivo
4.
Identificativo, IP e porta di ascolto del secondo nodo successivo
5.
Identificativo, IP e porta di ascolto del Naming Server
6.
Identificativo, IP e porta di ascolto del Database Server
7.
Identificativo del contenuto
8.
Tipo del contenuto (statico o dinamico)
Il package ThreadPool contiene l’implementazione di un pool di thread e consente di mettere in
esecuzione o di accodare, se si è raggiunto il massimo numero di thread (impostato a 5
nell’implementazione di BlueMark), un generico thread tramite il metodo doTask(Runnable task).
Package BlueMarkCorbaClient
Realizza l’iterazione con il Naming Service permettendo al Proxy di ottenere, attraverso l’handle
sull’oggetto remoto ed il metodo downloadFile, il file specificato. Il file viene memorizzato dal Proxy
nella cartella buffer locale ‘C:/tmp/proxybuffer’ e, nel caso di contenuto statico, non viene più
richiesto al BlueMark Server se già presente nella cartella buffer.
Package BMProxyDB
Questo package permette le interazioni tra il Proxy ed il database MySQL locale. La classe
MySqlDb.java implementa la classe astratta DBManager.java definendo le principali operazioni SQL
sul database MySQL.
La classe DBUtils.java, servendosi dei metodi definiti in MySqlDb.java, implementa tutti i metodi
necessari ad interfacciare il Proxy con il database.
Ogni modifica in scrittura sul database viene propagata lungo l’anello logico tramite l’invio di un
messaggio opportunamente definito. L’identificativo del Proxy allegato al messaggio permette di
bloccare il forwarding del messaggio quando esso giunge al Proxy precedente dell’anello ed evitare
quindi inutili ritrasmissioni.
La classe DbUpdater.java, infine, permette di effettuare automaticamente le operazioni di update del
database in base ai messaggi ricevuti dai Proxy nella token ring attraverso il metodo
update(BMMessage message).
Le seguenti immagini mostrano la struttura della tabella ‘contenttable’ presente in ciascun Proxy che
costituisce lo stato globale del sistema BlueMark.
La tabella sarà presente in ogni Proxy ed il contenuto dovrà essere gestito in modo da garantire
coerenza nell’applicazione delle politiche di gestione.
Il campo ‘Proxy’ identifica il Proxy che ha trattato o sta trattando l’invio verso un determinato
dispositivo identificato dall’UUID.
Il campo ‘Status’ contiene lo stato associato al dispositivo. Può assumere i seguenti valori:
- SENDING: è in corso il tentativo di invio del contenuto verso il dispositivo client
- SENT: l’invio del contenuto è terminato con successo
- DENIED: l’invio del contenuto non è stato autorizzato dal possessore del dispositivo
- TIMEOUT: il possessore del dispositivo non ha risposto alla richiesta o si è verificato un errore
nella trasmissione
Package BluetoothUtils
E’ uno dei package più complessi di BlueMark Proxy poiché al suo interno sono implementate tutte le
funzionalità relative alla connessione Bluetooth.
L’entità fondamentale è il thread BTManager implementato in BTManager.java attraverso il quale
vengono gestite le fasi di discovery dei dispositivi e, alla ricezione del token, il push dei contenuti ai
dispositivi applicando le politiche di invio citate nell’analisi dei requisiti. Viene quindi effettuato il
passaggio del token che abilita il Proxy successivo.
La classe BlueToothInquirer.java implementa il thread incaricato del discovery dei dispositivi. La
fase di discovery è sempre attiva ed indipendente dalla ricezione del token. I dispositivi rilevati sono
inseriti in una hashtable dalla quale saranno prelevati alla ricezione del token, sarà verificato il loro
stato sul database e, nel caso sia possibile inviar loro il contenuto, sarà inserito il thread definito da
OBEXPushUtility.java nel Thread Pool. In questo momento al dispositivo sarà associato lo stato
‘SENDING’.
La politica di gestione di BlueMark prevede che sia possibile tentare l’invio solo nel caso in cui il
dispositivo non sia inserito nel database (e sia quindi una ‘nuova scoperta’) o nel caso in cui sia in
stato ‘TIMEOUT’.
In tutti gli altri casi il dispositivo viene ignorato poiché già gestito da un altro Proxy.
Al termine delle proprie operazioni il thread OBEXPushUtility stabilisce il risultato dell’invio.
La gestione del timeout è affidata al thread Timer.java che allo scadere di un intervallo temporale
prefissato pone a ‘TIMEOUT’ lo stato del dispositivo ed annulla l’invio.
E’ utile sottolineare che il token può essere passato subito dopo aver posto i dispositivi verso cui si
tenta l’invio in stato ‘SENDING’ poiché tale stato è sufficiente per impedire al Proxy successivo di
tentare un invio verso quel dispositivo. Il risultato finale dell’operazione di invio può essere quindi
trasmesso anche successivamente al passaggio del token. Tale scelta deriva inoltre dalla necessità di
fare fluire il token nell’anello senza dover attendere la terminazione di tutti gli invii che, in caso di
‘TIMEOUT’ si prolunga di molto. I dispositivi che generano un ‘TIMEOUT’ saranno comunque
ricontattati dal primo proxy che, durante l’esecuzione, possiede il token ed ha trovato lo stesso
dispositivo in fase di discovery.
Inoltre lo stato di ‘TIMEOUT’ si rivela fondamentale nella gestione della fase di recovery.
Si sottolinea infine che lo stato che potremmo chiamare ‘DISCOVERED’ non viene tracciato poiché
inutile ai fini dell’applicazione delle corrette politiche di funzionamento del sistema. Infatti anche se
fossero mantenuti in modo persistente tutti i dispositivi trovati non sarebbe possibile ne escluderli da
successive fasi di discovery e nemmeno dare per scontata la loro persistenza all’interno del range di
copertura in modo da “bypassare” il discovery stesso. Inoltre tale stato può essere tranquillamente
ignorato in fase di caduta del nodo e quindi è inutile anche ai fini della fase di recovery.
Provocherebbe, al contrario, una grossa mole messaggi di aggiornamento lungo l’anello.
Package TokenRing
Il package TokenRing.Message definisce struttura e tipologie di messaggi e token che circolano nel
ring logico.
Il package TokenRing.Socket realizza invece una mailbox (MessageBoxThread) attraverso socket TCP
di input ed output definite dalle classi InputThread.java ed OutputThread.java.
Il MessageBoxThread si occupa di gestire ricezione ed invio dei messaggi e dei token sia un fase di
funzionamento normale sia in fase di recovery. Provvede ad attivare la fase di recovery nel caso si
verifichi un timeout sul canale di input ed inoltre svolge il delicato di compito di “smistare” i
messaggi al manager del database per consentire il corretto aggiornamento del database. Gestisce
automaticamente le operazioni di forwarding dei messaggi e la persistenza dei messaggi di
input/output in caso di malfunzionamenti.
Il package TokenRing.Recovery contiene l’implementazione delle operazioni necessarie a ripristinare
il corretto funzionamento del sistema. In esso sono presenti la classe relative al thread coordinatore
(CoordinatorRecoveryThread.java) e quella relativa al generico thread di recovery
(RecoveryThread.java). Entrambi implementano l’interfaccia RecoveryThreadInterface.java.
Package core
Costituisce l’entry point di BlueMark Proxy. La classe Main.java riceve in input il file di testo
contenente la configurazione del nodo e mette in esecuzione il thread Proxy definito in
ProxyNode.java.
Il thread Proxy, dopo avere impostato i parametri di configurazione, avvia il database manager ed il
Corba client ottenendo un handle sull’oggetto remoto.
Successivamente determina, dai parametri di configurazione, se il Proxy è unico (modalità
standalone) oppure inserito in una token ring. Nel primo caso avvia il discovery e ad intervalli
prefissati si auto-abilita agli invii.
Nel secondo caso viene avviato il thread relativo alla mailbox ed inizia la fase di inizializzazione.
Il solo Proxy avente identificativo ‘1’ effettua ripetuti tentativi di invio del token BNINITTOKEN che
abilita i Proxy lungo l’anello e avvia le operazioni di discovery. Alla ricezione dello stesso token, che
segnala quindi la corretta configurazione dell’anello, il Proxy ‘1’ crea ed avvia la circolazione del
token BMTOKEN che abilita le operazioni di invio.
Availability: Fase di Recovery
La fase di recovery ha come obiettivo il ripristino della token ring e del corretto funzionamento del
sistema in seguito alla caduta di un Proxy. Si ipotizza il guasto singolo e si garantisce quindi il
recovery in questo caso. Nella trattazione della fase di recovery si farà riferimento al caso mostrato in
figura sottostante cioè una Token Ring di 5 Proxy in cui il Proxy 2 ha cessato di funzionare.
Il malfunzionamento verrà “percepito” sia dal Proxy 1 (sul canale di output) che dal Proxy 3 (sul
canale di input).
Il Proxy 1, in seguito a ripetuti tentativi di invio non riusciti, memorizza i messaggi in output evitando
quindi di perderli definitivamente. L’avvio della procedura di recovery avviene sempre dal nodo
successivo a quello caduto (il Proxy 3 nel caso dell’esempio) con l’invio del token
BMELECTIONTOKEN che segnala l’avvio della procedura di recovery e al tempo stesso comunica ai
Proxy l’identificativo del coordinatore e del nodo caduto. In questo modo ulteriori avvii di procedure
di recovery, dovute al verificarsi del timeout sulla accept nel thread di input, non daranno luogo ad
inconsistenze dovute alla presenza di due o più coordinatori.
Pertanto alla ricezione del BMELECTIONTOKEN i nodi non coordinatori avvieranno il thread
RecoveryThread e passeranno il token verificando che il nodo caduto non sia il successivo. In questo
caso il forward avverrà al secondo nodo successivo (cioè il coordinatore), scavalcando quindi il nodo
caduto.
Al ritorno del token al Proxy 3 viene avviato il RecoveryCoordinatorThread che provvede a
coordinare il recovery.
Tutti i messaggi in input o in output generati dai Proxy non sono quindi ora inviati ma inseriti in
apposite strutture dati in modo da poter essere recuperati al termine del recovery.
Il Proxy coordinatore invia ora il BMRECOVERYTOKEN avente lo scopo di ottenere tutte le
informazioni necessarie al ripristino dell’anello.
Pertanto il Proxy 1 dovrà aggiornare il token con il proprio identificativo in modo da stabilire il nuovo
nodo precedente al coordinatore ed il Proxy 4 dovrà settare il proprio identificativo per comunicare al
Proxy 1 il nuovo nodo secondo successivo.
Inoltre il nodo possessore del BMTOKEN lo comunicherà segnalando il proprio identificativo nel
token stesso.
Al ritorno del BMRECOVERYTOKEN, il coordinatore sarà quindi in possesso di tutte le informazioni
necessarie alla ricostruzione dell’anello.
Tutte queste informazioni sono inviate con il token BMUPDATETOKEN grazie al quale tutti i proxy
aggiornano le proprie strutture dati e, al ritorno del token al coordinatore, il ring logico è stato quindi
ripristinato.
A questo punto viene riattivata la messagebox su tutti i nodi per poter gestire i messaggi bufferizzati
durante la fase di recovery ed aggiornare quindi correttamente tutti i database.
Prima di ripartire è necessaria un’ulteriore operazione: il proxy caduto potrebbe aver lasciato dei
dispositivi in stato ‘SENDING’ senza aver completato le operazioni di invio. Per evitare che tali
dispositivi siano, come da politiche di sistema, ignorati, è opportuno portare i soli dispositivi associati
al proxy caduto dallo stato ‘SENDING’ allo stato ‘TIMEOUT’ in modo da consentire successivi invii.
Nessuna operazione invece sarà fatta per i dispositivi aventi stato finale ‘SENT’ o ‘DENIED’.
Potrebbero verificarsi 2 richieste di invio consecutive ad un dispositivo già in stato finale se la caduta
si verificasse tra la fase di invio e l’invio dei messaggi di aggiornamento finali (che sarebbero
inevitabilmente persi). Per evitare tale problema sarebbe sufficiente porre a ‘DENIED’ ogni
dispositivo in stato ‘SENDING’ associato al proxy caduto. In questo modo però potrebbero non
ricevere il contenuto anche i dispositivi che hanno accettato esplicitamente.
Si è scelto pertanto la prima strada non considerando l’invio di due sole richieste (peraltro
conseguente a concause non frequenti) come un fenomeno di “blueSpam”. Al contrario il mancato
invio di un contenuto ad un utente che lo desideri costituisce un grosso problema in termini di
availability e QoS.
La procedura di recovery termina facendo ripartire il BMTOKEN dal nodo possessore o, nel caso il
token sia stato perduto, dal nodo coordinatore che provvede a ricrearlo.
La procedura di recovery funziona correttamente anche in caso di ulteriori guasti singoli fino a
portare il sistema in una condizione di Proxy standalone.
Fase di Test
Configurazione Hardware / Software
Nella fase di test del progetto sono stati utilizzati due PC collegati tramite rete locale. A ciascuno è
stato collegato un adattatore USB Bluetooth di classe II (copertura 10 metri). Il sistema operativo è
per entrambi Windows XP con SP2. Si è utilizzato inoltre il JRE 1.5.0_06.
Dell Dimension 4550 ‘NOMAD’
(Pentium 4 2.53GHz 384MB RAM)
con Belkin FBT003v2
Indirizzo IP: 192.168.1.5
Dell Latitude D800 ‘D800’
(Pentium M 1.70GHz 512MB RAM)
con D-Link Bluetooth DBT-120
Indirizzo IP: 192.168.1.2
Tutti i test sono stati effettuati utilizzando il Naming Service di Java (orbd) su porta 1050 e il
database MySQL Community Edition 5.0.41 su porta 3306. Per semplicità entrambe le istanze sono
in esecuzione sul Dell D800. In condizioni operative reali sarà necessario installare, per avere
maggiore affidabilità, il database MySQL su ogni dispositivo hardware in modo da tollerare una reale
caduta hardware. Nella fase di test si simula infatti la caduta del Proxy terminandone “brutalmente”
(Ctrl+c) l’esecuzione e non spegnendo o danneggiando il sistema fisicamente.
Come già evidenziato è possibile impostare Token Ring, Naming Service e Database Server tramite il
file testuale di configurazione.
Dispositivi Bluetooth
I dispositivi bluetooth utilizzati come Client durante i test sono:



Telefono cellulare Sony Ericsson T610 (UUID: 000e072431db)
Telefono cellulare Nokia 6151 (UUID: 001bee5283f2)
Bluetooth integrato nel portatile D800 (UUID: 0010c65abadc)
Introduzione ai test
Per ogni test effettuato sono riportati, all’interno della cartella ‘Test’, i relativi file di configurazione
(cartella ‘config’) ed i log di esecuzione dei Proxy coinvolti. Il comportamento del Server è inserito
unicamente nel primo test ed è stato omesso dai successivi poiché sostanzialmente identico.
Test #1: Esecuzione base (un unico Proxy)
Questo test è propedeutico ai test successivi e permette di comprendere il funzionamento del sistema
senza valutarne l’affidabilità essendo in esecuzione sullo stesso nodo il BlueMark Server ed un unico
BlueMark Proxy. Osservando l’esecuzione del Server si nota infatti come il file, che successivamente
sarà inviato ai dispostivi Client consenzienti, venga inviato al Proxy una sola volta. Ciò si verifica
poiché il Proxy in caso di contenuti definiti statici memorizza il file nella cartella temporanea e non
richiede al server il file ad ogni invio.
Dall’esecuzione del Proxy invece di può notare che il sistema rileva tutti e tre i dispositivi e tenta
quindi l’invio. Si può verificare che il D800 ed il Nokia 6151 hanno accettato e ricevuto il contenuto
mentre il T610 ha rifiutato il contenuto. L’immagine sottostante mostra lo stato del database del
Proxy al termine delle operazioni appena commentate.
In seguito a questo test è interessante rilevare che, tra l’avvio del BlueMark Proxy e la ricezione del
file sul primo dispositivo che lo accetta, sono trascorsi circa 30 secondi assumendo che il possessore
del cellulare attenda 3 secondi prima di accettare il file. Le velocità di trasferimento del file sono
inoltre variabili in base al dispositivo Client.
Test #2: Esecuzione (due Proxy su due nodi differenti)
In questo test si sono verificate le reali interazioni nel caso di due Proxy.
Il BlueMark Proxy è stato quindi avviato su ciascuno dei due nodi identificando come Proxy ‘1’
quello in esecuzione sul D800 mentre come Proxy ‘2’ quello sul Dimension 4550.
Dal log dell’esecuzione si può notare come i due Proxy si coordino negli invii evitando richieste
ripetute allo stesso dispositivo. Tutti e tre i dispositivi accettano l’invio e ricevono quindi il contenuto.
L’esecuzione su due nodi ha evidenziato che il dispositivo Bluetooth D-Link è, rispetto al dispositivo
Bluetooth Belkin, leggermente più veloce in fase di discovery dei dispositivi client.
La fase di discovery risulta essere quella più onerosa in termini di dispendio di tempo (all’incirca 10
secondi) pertanto la scelta di un dispositivo bluetooth non efficiente può influire negativamente sulle
prestazioni dell’intero sistema.
In condizioni operative reali sarà opportuno utilizzare adattatori Bluetooth di classe I che offrono,
oltre ad una maggiore copertura, maggiore velocità nelle operazioni di discovery e trasferimento dei
contenuti.
Test #3: Esecuzione con timeout nell’invio (due Proxy su due nodi differenti)
Lo scopo di questo test è stato di simulare il comportamento del sistema nel caso in cui il possessore
del dispositivo Client non si accorga della richiesta di invio del file, si attardi nella risposta o, come
ultima ipotesi, si verifichi una disconnessione durante il trasferimento a causa dello spostamento del
client al di fuori del range di copertura del dispositivo bluetooth associato al Proxy.
In tutti questi casi il sistema dovrà quindi associare al dispositivo lo stato ‘TIMEOUT’ e, nel caso di
successivi rilevamenti del dispositivo client, dovrà ritentare l’invio.
Le immagini si riferiscono alla tabella ‘contenttable’ relativa al Proxy ‘2’ prima e dopo l’invio del
contenuto al dispositivo client 000e072431db e mostrano come il sistema, in seguito al timeout
rilevato dal Proxy ‘1’, sia in grado di inviare il contenuto tramite il Proxy ‘2’ aggiornando lo stato
correttamente al termine delle operazioni.
Test #4: Esecuzione (cinque Proxy complessivi su due nodi diversi)
L’esecuzione di questo test ha evidenziato come sia possibile estendere la token ring anche a più di
due Proxy. In un contesto reale (con, ad esempio, 5 adattatori bluetooth) si hanno, notevoli vantaggi
sia in termini di velocità dei trasferimenti sia ovviamente in termini di area di copertura.
Nell’esempio si sono eseguiti i Proxy ‘1’ e ‘2’ su D800 ed i Proxy ‘3’,’4’,’5’ su Dimension4550.
Il portatile D800 è stato allontanato dal Dimension4550 in modo da non sovrapporre i range di
copertura e testare il sistema in caso di effettiva distribuzione spaziale dei Proxy.
I dispositivi Client sono stati così distribuiti: i due cellulari sono stati lasciati accanto al
Dimension4550 (cioè ai Proxy ‘3’,’4’ e ‘5’) mentre il dispositivo Client inglobato nel case del
portatile è , ovviamente, all’interno del range di copertura dei Proxy ‘1’ e ‘2’.
Tutti e tre i dispositivi Client rilevati hanno accettato l’invio ed i Proxy ‘1’,’3’ e’4’ hanno effettuato i
trasferimenti dopo aver richiesto al server il contenuto da inviare.
Il Proxy ‘1’ ha gestito il solo dispositivo client nel proprio range (quello integrato nel D800 stesso) e
in seguito al riavvicinamento del portatile D800 al Dimension4550 non è stato più ricontattato dai
Proxy ‘3’,’4’ e ‘5’.
Test#5: Esecuzione e fase di recovery (cinque Proxy complessivi su due nodi diversi)
La configurazione dei dispositivi resta invariata rispetto a quella utilizzata nel test precedente.
Sono stati attivati il dispositivo Client T610 e D800 mentre il bluetooth del Client Nokia6151 è stato
momentaneamente disattivato. Come si può notare dai log di esecuzione i dispositivi sono stati
rilevati e al D800 è stato inviato il contenuto. Il T610 ha risposto negativamente all’invito di invio.
E’ stato quindi simulato un guasto sul Proxy ‘4’ che ha portato all’avvio della fase di recovery avente
come coordinatore il nodo successivo, cioè il Proxy ‘5’. Al termine della fase di recovery, è stato
attivato il dispositivo Client Nokia 6151 e ad esso viene inviato il contenuto dal Proxy ’5’
dimostrando il corretto funzionamento del sistema anche dopo la fase di recovery.
Gli altri due dispositivi Client sono rimasti attivi e nel range di copertura ma non sono più stati
ricontattati poiché già gestiti precedentemente.
La fase di recovery viene gestita correttamente anche in seguito a nuove cadute fino al
raggiungimento della modalità standalone. Il sistema pertanto continua a funzionare sempre, ed anche
con un solo Proxy, a patto che, come ipotizzato, si verifichino guasti singoli.
Conclusioni, problematiche e sviluppi futuri
Il sistema BlueMark raggiunge gli obiettivi prefissati garantendo in particolare alta availability e il
rispetto delle politiche richieste.
Il valore del timeout sul canale di input costituisce un parametro fondamentale per il corretto
funzionamento dell’intero sistema e deve essere calibrato in modo da non avviare la procedura in caso
di semplice congestionamento ma solo in caso di effettiva caduta. Si potrebbe pertanto inserire nel
ring un token del tipo BMRINGALIVE che viene semplicemente passato all’interno dell’anello senza
dipendere dal completamento di operazioni sul Proxy (come avviene per il BMTOKEN).
Essendo stato sviluppato a scopo di progetto la maggior parte dei parametri sono stati “cablati” nel
codice. Pertanto come sviluppo futuro si potrebbe rendere possibile l’impostazione di questi parametri
tramite, ad esempio, una semplice interfaccia grafica.
Durante i test sono stati evidenziati problemi di gestione delle connessioni Bluetooth. Nel caso infatti
si verifichi una disconnessione dal dispositivo durante il trasferimento si possono creare condizioni di
instabilità che talvolta hanno causato il blocco del Proxy associato (e l’avvio della fase di recovery).
Tali aspetti sono stati volontariamente tralasciati in quanto esulano dagli obiettivi del progetto.
Sarebbe opportuno testare il sistema con una moltitudine di dispositivi Client in modo da verificare la
effettiva prestazione in caso di ‘affollamento’ di dispositivi. Sarebbe inoltre utile verificare la corretta
comunicazione tra Proxy e dispositivi Client ed in particolare la giusta percezione da parte del Proxy
delle risposte positive e negative dei Client. Una errata percezione della risposta, ad esempio negativa,
genera fastidiose ritrasmissioni al dispositivo Client.
Si è tentato inoltre di effettuare un ultimo test inviando due contenuti diversi ad ogni dispositivo
Client trovato. Ciò non è stato possibile poiché ad ogni Proxy è associata nel database una unica
tabella ‘contenttable’ che non discrimina sulla base del contenuto.
Per risolvere il problema è sufficiente creare una tabella ‘contenttable’ per ogni contenuto ed
effettuare una banale modifica a livello di codice che associa ogni contenuto alla relativa tabella del
database.