Fluidtime Bluetooth Server

Antonio TerrenoJava DevelopmentFluidtime GmbH

Antonio Terreno

Laureato in Informatica

Mobile Development & Research at Fluidtime Data Services GmbH

Java Mobile Developer ForumJava User Group TorinoJava2Me.Org...javaday.it

Java Mobile Developer Forum?

JMDF!

http://groups.yahoo.com/group/jmdf/

incontri mensili

repository di conoscenze

laboratorio per il test delle applicazioni

progetti open-source

eventi (code-camp) per gli sviluppator

valore aggiunto alle aziende > database di skill tecnici degli sviluppatori

Java User Group Torino

JUGTO!

360 members

86.000 visitatori sulla ML dal luglio 2002

100 Visite in media ogni giorno

http://groups.yahoo.com/group/it-torino-java-jug/

http://www.jugtorino.it/vqwiki/jsp/Wiki

Javaday?

Torino 7 LuglioCagliari 16 SettembreMilano 28 SettembrePisa 14 OttobreNovara 18 NovembrePalermo 24 NovembreRoma 2 Dicembre

http://www.javaday.it

JavaDay a Torino

Un programma mica male...

Bruno Bossola [Jug.To] – Object Oriented per non credenti

Jason Van Zyl (Maven main committer) – Maven in Action (in inglese)

Nino Guarnacci [JIP] & Francesco Manenti – Ajax & SOA

Greg Wilkins (Jetty creator) – Jetty in Action (in inglese)

Gribaudo Marco [Uni.To] – DrawNET: uno strumento flessibile per la valutazione delle prestazioni dei sistemi

Baldoni Matteo /Guido Boella [Uni.To] – powerJava: ruoli per modellare l'interazione in Java

Agenda della presentazione

Ok ok ora si comincia...

i requisiti del cliente

lo sviluppo del server

le tecnologie utilizzate

l'hardware utilizzato

i limiti della tecnologia

... e come superarli

conclusioni

I requisiti

Una vera e propria black box autonoma con...

buone prestazioni, basso consumo di energia

“plug and play”

resistente a tutto

affidabile

trasportabile

Sviluppo

Si parte con un semplice Bluetooth Server Obex

mono thread

discovery dei devices

discovery dei servizi, ma perché poi?

push

Bluetooth?

Cos'è?

standard

economico

sicuro? sicuro che è sicuro?

onde radio...

Il nome è stato ispirato da Harald Blåtand, ovvero re Aroldo I di Danimarca, abile diplomatico. Gli inventori della tecnologia devono aver ritenuto che fosse un nome adatto per un protocollo capace di mettere in comunicazione dispositivi diversi.

Bluetooth è vivo, bluetooth è morto

Lo sviluppo è fermo o no?

1.0, 1.1, 1.2, 2.0...

2.0 va a 2,1 Mbit/s, quality of service, tempi ridotti

Lisbon: 3 Mbit/s,

Seattle: Ultra wideband

http://www.intel.com/technology/comms/uwb/

Bluetooth è vivo!

Nokia mette il 2.0 sui suoi cellulari (6125 xes), intel gli dedica una pagina...

Obex?

Cos'è l'Obex?

Obex sta per OBject Exchange

E' un protocollo di comunicazione che favorisce lo scambio di oggetti tra devices

Trasporto implementato sopra lo stack Baseband/Link Manager/L2CAP/RFCOMM

Trasmissione: binaria

Supporto della sessione

OpenObex è l'implementazione open di riferimento

Ma noi lavoriamo con bluetooth < 2.0

Il server non va bene

lento

stupido

soffre troppo delle limitazioni delle connessioni bluetooth

I requisiti, atto secondo

Mettiamoci sopra un po' di intelligenza e un po' di follia!

riconoscimento dei device

multithreaded

multiantenna

Il riconoscimento dei devices

Via Bluetooth non si ottengono direttamente informazioni sul dispositivo remoto

mai sentito parlare però di Blueprinting?

Il server ha un database (xml) dei devices

una funzione euristica cerca di riconoscere quale tipo di device sta dall'altra parte

tramite le capabilities bluetooth

Il riconoscimento dei devices

Si può fare o non si può fare?

Every bluetooth-enabled device has some characteristics that are either unique (Bluetooth device address)

maufacturer specific (the first part of the bluetooth device address)

model-specific (service description records).

Blueprinting is combining... bla bla bla

Il fascino dei commerciali

Certo che si può fare... Ho visto quel sito...

Ok, uno script in perl assurdo

Fatti due test/due mail su jmdf i mac adress sono tutti diversi (anche da un firmware all'altro)

però però....

l'idea delle capabilities non era così male...

Il nostro database

Un serverino che fa solo device discovery e service search

Scrive giù cosa trova

Noi sappiamo su quali cellulari stiamo facendo search

Ci scriviamo un bell'xml

Abbiamo un database xml...

Il riconoscimento dei devices

Il database dei devices è molto semplice, ed viene parsificato con Javolution

<device name="nokia_6600" file="files/6600.html"><capabilities>

<capability value="Fax" /><capability value="Dial-up Networking" /><capability value="Bluetooth Serial Port" /><capability value="OBEX Object Push" /><capability value="OBEX File Transfer" /><capability value="Handsfree Audio Gateway" />

</capabilities></device>

Javolution

Quando si lavora sul piccolo, per me è una scelta obbligata

da CLDC 1.0 fino a JDK 1.5

Safe/transparent object recycling (faster than memory recycling, aka GC).

Fast/easy parallel computing support with concurrent contexts.

High performance and real-time compliant util / lang / io / xml base classes.

Struct and Union base classes for direct interfacing with native applications.

Java fastest xml parsing and marshalling/unmarshalling facility.

grande supporto da parte di Jean-Marie Dautelle

Il riconoscimento dei devices.. sognando l'intelligenza totale

Sarebbe bello...

se il server aggiornasse automaticamente il proprio db

se il server potesse integrarsi con servizi come il WURFL database

se potesse riconoscere senza il minimo errore modello e marca

attualmente tuttavia non si comporta per niente male!

Il multithreading

Con la tecnologia Bluetooth si possono tenere aperte su una singola antenna fino a 7 connessioni

perchè non usarle tutte quindi?

invio concorrente con controllo delle conessioni totali

ovviamente non ci siamo ancora... se il client remoto non risponde dobbiamo aspettare almeno un minuto prima che la connessione venga rilasciata...

perdiamo ancora troppo tempo!

per riconoscere i devices siamo costretti a fare una service search sul dispositivo...

Una, due, cento antenne

Perchè non mettere più di un'antenna quindi?

Con più antenne possiamo servire contemporaneamente più di 7 dispositivi

grazie alle librerie bluetooth avetana ciò è possibile

piccoli problemi:

dobbiamo rendere il server non solo multithread ma anche multi istanza

dobbiamo gestire l'invio concorrente da parte di più istanze su più thread...

Che fortuna...

L'implementazione (open) della jsr82 di avetana

E' open

Si integra alla perfezione con lo stack bluetooth per linux Bluez

Permette di inizializzare lo stack su una particolare antenna

Se si hanno dei problemi il buon Moritz Gmelin non esita a risponderci

Non ci resta che scrivere il codice!

Un'antenna un'istanza

Il nostro server comincia a diventare complesso...

Dobbiamo tenere traccia di cosa stiamo mandando e a chi

Dobbiamo avere un semaforo condiviso tra le istanze

Dobbiamo tener presenti i requisiti prestazionali...

Idea JNDI

Da un articolo di Thomas E. Davis apparso su Javaworld nel 1999...

Il buon Davis ci propone un'implementazione di un HashTable JNDI

Ma è perfetta per noi!

Utilizzando filesystem, non DB, non LDAP ovviamente!

A questo punto abbiamo un file a cui possiamo accedere in modalità concorrente

Idea JNDI

Ma anche gli italiani ne parlano...

JNDI, la API Java(TM) per i servizi di Naming e Directory, è forse una delle più sottovalutate.

http://www.mokabyte.it/2002/01/jndi_1.htm

Per i pigri.. Anche in italiano

di Fabrizio Giudici, MokaByte 59 - Gennaio 2002

JNDIHashTable

Un po' di codice... public synchronized Object put(Object key, Object value) { Object previous = get(key);

try { try { context.bind((String) key, value); } catch (NameAlreadyBoundException ex) { context.rebind((String) key, value); } } catch (NamingException e) { e.printStackTrace(); }

return (previous); }

Forte no?

Abbiamo un Service Locator... Un context...

Il tutto dentro un pc linux embedded

I vari server che si occupano del pushing vi accedono

Un server “specializzato” nel discovery dei devices popola la tabella

lo stato di invio è costantemente aggiornato

La concorrenza è gestita tramite un flag su ogni device che funge da mutex

Il SendingStatus

E' l'oggetto che finisce nella JNDIHashTable

implementa Referenceable e Serializable

per ottenere un'istanza di SendingStatus usiamo una SendingStatusFactory

che implementa ObjectFactory

contiene tutte le informazioni necessarie al ciclo di vita del server

numero di invii, file inviato, obex url

L'Hardware

Un pc in una scatola

un Celeron a 450Mhz

512Mb di Ram

Se fa troppo freddo si autoriscalda prima di partire

completamente impermeabile

resistente da -30° a +70°

Linux Ubuntu installato su di una CF da 1GB

I limiti del bluetooth

E' proprio dura averla vinta con questa tecnologia!

il limite delle 7 connessioni

il limite dei 10 metri

la perdita di segnale

il problema del baseband

aspettando seattle, lisbon, intel, speriamo bene...

Baseband?

Già, il bluetooth trasmette in banda base...

si utilizza una sola frequenza portante su di un solo canale

si trasmette una sola unità di rete per volta

thanks to Marcel Holtmann (Bluez)

Conclusioni

Ma che divertimento!

tanti problemi ma anche tanto divertimento

il core del server... E' stato (ri)scritto 4-5 volte

occhio a log4j...

varcare i limiti o starci a cavallo è sempre una bella esperienza!

Riferimenti

Qualche sito citato durante la presentazione...

Avetana JSR 82

Javolution

trifinite blueprinting

Articolo JavaWorld

bluez

openobex

Domande e risposte

Antonio TererenoMobile Development Fluidtime data services GmbH

antonio.terreno@fluidtime.comwww.fluidtime.com