Slideshare.net (beta)

Slide 1: Fluidtime Bluetooth Server Antonio Terreno Java Development Fluidtime GmbH

Slide 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

Slide 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

Slide 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

Slide 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

Slide 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

Slide 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

Slide 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

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

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

Slide 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/

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

Slide 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

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

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

Slide 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

Slide 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

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

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

Slide 20: 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>

Slide 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

Slide 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!

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

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

Slide 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!

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

Slide 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

Slide 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

Slide 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); }

Slide 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

Slide 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

Slide 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

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

Slide 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)

Slide 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!

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

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