BlueMar
Sistema di Proximity k
Marketing con QoS ed availability
Progetto per il Corso di Reti di Calcolatori LS
Nicola Bonoli - 27 Giugno 2007
Scenario
Affermazione e diffusione della
tecnologia Bluetooth ®
Blue
Mar
k
Possibilità di inviare contenuti
di svariato genere ai dispositivi
consenzienti a costo zero!
Obiettivi
 Distribuire contenuti multimediali verso dispositivi abilitati
alla ricezione Bluetooth ®
 Permettere la corretta cooperazione di più trasmettitori
indipendentemente dalla posizione
 Evitare il “BlueSpam”
 Garantire l’availability del sistema a fronte di situazioni di
guasto singolo
 “Occhio di riguardo” alla QoS
Attori

Client(i): dispositivo con Bluetooth ® attivato ed in stato “rilevabile”

Proxy(i):
- Discovery dei dispositivi client
- verifica lo stato e gestisce la trasmissione dei contenuti.
- Si coordina con gli altri proxy e deve poter garantire la continuità del servizio.
- Attenzione a gestione risorse e QoS.

Server:
- Fornisce i contenuti ai proxy.
- Supporta richieste concorrenti
- Non è richiesta availability lato server
BlueMar
kServer
Client
Server
BlueMa
rkProx
y
Proxy i
Macroscelte Progettuali
(…WS  )
 Interazione server - proxy  CORBA
 Persistenza  database MySQL
{
Integrazione
Eterogeneità
Concorrenza
BlueMark Server
BlueMark Proxy





Bluetooth  BlueCove (JSR-82) & Avetana OBEX
Persistenza  database MySQL
Comunicazione tra Proxy socket TCP
Availability  replicazione decentralizzata e Token Ring
(Load balancing)  Thread Pool
Architettura Finale
BlueMark Proxy
BlueMark Proxy
BlueMark Proxy
BlueMark Server
BlueMark Server
Database dei contenuti (una tabella per ogni contenuto)





Tipo di dispositivo (Tailoring…)
Nome del file
Tipo di contenuto (Mp3,Gif…)
Percorso locale
Contenuto statico / dinamico
Configurazione del Server
Corba Server 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);
};
Naming
Service!!!
BlueMark Proxy:
configurazione e struttura
Configurazione di BlueMarkProxy








Identificativo, IP e porta di ascolto del nodo
Nodo precedente nel ring logico (recovery)
Nodo successivo (forwarding)
Secondo nodo successivo (recovery)
Naming Service
Database Server
Identificativo del contenuto
Contenuto statico / dinamico
Buffering del contenuto
(se contenuto statico)
Init
Remote Devices
Utilities
ThreadPool
BlueMark
CorbaClient
TCP
Mailbox
TokenRing.Socket
Core
(Entry Point & INIT)
TokenRing.Message
BluetoothUtils
TokenRing.Recovery
BMProxyDB
BlueMark Proxy:
funzionamento principale

UUID
(1) Discovery del dispositivi (continuo)
(2) Ricezione del Token (BMToken)

OBEXPort

Stato associato al dispositivo:
–
–
–
–
Sending
Sent
Denied
Timeout
(3) Verifica dello stato ed eventuali
tentativi di invio
(4) Forwarding del Token
(Stato ‘Discovered’ non tracciato…)

Proxy
Politica di invio  invia se non presente o in stato timeout
Proxy Availability





Procedura di recovery per far fronte a
guasto singolo
Funzionamento del sistema anche in
modalità standalone
Rilevamento del guasto basato sulle
primitive TCP
Mailbox con buffer durante il recovery
Nodo successivo al guasto diventa
Coordinatore
BlueMark Proxy 1
BlueMarkProxy 5
BlueMark Proxy 4
BlueMark Proxy 2
BlueMark Proxy3
(coordinator)
Procedura di Recovery
1
BMELECTIONTOKEN
 Avvio coordinatore.
 Comunicazione del nodo caduto
2
BMRECOVERYTOKEN
 Individuazione di:
- possessore del BMTOKEN
- nuovo precedente al coordinatore
- nuovo secondo successivo
3
4
BMUPDATETOKEN
 Ripristino del ring logico
 Riattivazione della mailbox
 Aggiornamento del database
( Sending(downproxy)Timeout )
Riattivazione
(BMTOKEN rigenerato dal coordinatore
se smarrito )
BlueMark Proxy 1
BlueMarkProxy 5
BlueMark Proxy 4
BlueMark Proxy 2
BlueMark Proxy3
(coordinator)
Testing & Demo
BlueMark Server
BlueMark Proxy
• Test #1: Esecuzione base (un unico Proxy)
• Test #2: Esecuzione (due Proxy su due nodi differenti)
• Test #3: Esecuzione con timeout nell’invio (due Proxy su due nodi differenti)
• Test #4: Esecuzione (cinque Proxy complessivi su due nodi diversi)
• Test#5: Esecuzione e fase di recovery (cinque Proxy complessivi su due nodi diversi)
Conclusioni e sviluppi futuri

Il sistema BlueMark raggiunge gli obiettivi prefissati garantendo in particolare
availability e il rispetto delle politiche richieste. Supporto per eventuale QoS.
Sviluppi futuri:

Calibrazione timeout sul canale di input  token BMRINGALIVE

Impostazione dei parametri (timeouts, thread pool…)  interfaccia grafica

Soluzione di problemi di gestione delle connessioni Bluetooth

Invio di più contenuti allo stesso client dallo stesso proxy

Tailoring dei contenuti

Test del sistema in condizioni di alto carico