My speech at the Italian Java conference 2006 about my bluetooth box.

1. Fluidtime Bluetooth Server
Antonio Terreno
Java Development
Fluidtime GmbH

2. Antonio Terreno
Laureato in Informatica
Mobile Development & Research at
Fluidtime Data Services GmbH
Java Mobile Developer Forum
Java User Group Torino
Java2Me.Org
...
javaday.it

3. 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

4. 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

5. Javaday?
Torino 7 Luglio
Cagliari 16 Settembre
Milano 28 Settembre
Pisa 14 Ottobre
Novara 18 Novembre
Palermo 24 Novembre
Roma 2 Dicembre
http://www.javaday.it

6. 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

7. 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

8. I requisiti
Una vera e propria black box autonoma con...
 buone prestazioni, basso consumo di energia
 “plug and play”
 resistente a tutto
 affidabile
 trasportabile

9. Sviluppo
Si parte con un semplice Bluetooth Server Obex
 mono thread
 discovery dei devices
 discovery dei servizi, ma perché poi?
 push

10. 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.

11. 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/

12. Bluetooth è vivo!
Nokia mette il 2.0 sui suoi cellulari (6125 xes), intel gli dedica una pagina...

13. 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

14. Ma noi lavoriamo con bluetooth < 2.0
Il server non va bene
 lento
 stupido
 soffre troppo delle limitazioni delle connessioni bluetooth

15. I requisiti, atto secondo
Mettiamoci sopra un po' di intelligenza e un po' di follia!
 riconoscimento dei device
 multithreaded
 multiantenna

16. 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

17. 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

18. 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...

19. 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...

20. Il riconoscimento dei devices
Il database dei devices è molto semplice, ed viene parsificato con Javolution
<device name=quot;nokia_6600quot; file=quot;files/6600.htmlquot;>
<capabilities>
<capability value=quot;Faxquot; />
<capability value=quot;Dial-up Networkingquot; />
<capability value=quot;Bluetooth Serial Portquot; />
<capability value=quot;OBEX Object Pushquot; />
<capability value=quot;OBEX File Transferquot; />
<capability value=quot;Handsfree Audio Gatewayquot; />
</capabilities>
</device>

21. 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

22. 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!

23. 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...

24. 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...

25. 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!

26. 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...

27. 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

28. 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

29. 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);
}

30. 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

31. 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

32. 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

33. 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...

34. 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)

35. 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!

36. Riferimenti
Qualche sito citato durante la presentazione...
 Avetana JSR 82
 Javolution
 trifinite blueprinting
 Articolo JavaWorld
 bluez
 openobex

37. Domande e risposte
Antonio Terereno
Mobile Development
Fluidtime data services GmbH
antonio.terreno@fluidtime.com
www.fluidtime.com