Bluetooth i Java Czyli JSR-82 w akcji Sławomir Brański Mail: S.Branski@tt.com.pl Skype: branskislawomir

Agenda Bluetooth – krótka historia powstania, Warstwa sprzętowa, wspierane profile, JSR-82 – krótka historia i specyfikacja specyfikacja standardu, Przykład implementacji JSR-82 - Stos Bluecove: Klasa LocalDevice oraz DiscoveyAgent czyli wykrywanie innych urządzeń, Klasy RemoteDevice i ServiceRecord - pobieranie informacji o dostępnych serwisach Bluetooth, Model połączenia szeregowego – RFCONN typu serwer-klient, Model połączenia typu OBEX Push Nie będziemy mówić o Androidzie (to zupełnie inne standardy) Nie będziemy się zagłębiać w szczegóły techniczne odnośnie bezpieczeństwa

Bluetooth – historia powstania TSL włączone domyślnie Większa dostępność algorytmów opartych o AES SecureRandom i getInstanceStrong() – najsilniejsza dostępna implementacja Z bardziej znanych zmiany w dostępie przez Kerberos 5

Bluetooth – historia powstania

Bluetooth – historia powstania 1994 A.D. TSL włączone domyślnie Większa dostępność algorytmów opartych o AES SecureRandom i getInstanceStrong() – najsilniejsza dostępna implementacja Z bardziej znanych zmiany w dostępie przez Kerberos 5

Bluetooth – historia powstania Alternatywy? Używa fal podczerwieni do komunikacji: Nadajnik i odbiornik muszą się fizycznie widzieć (zero przeszkód na linii), Zasięg - teoretycznie do kilku metrów, w praktyce – metr, Niskie przepustowości (tak naprawdę „pod maską” kryje się UART) ówczesnych urządzeń, Ale pewien fragment specyfikacji idealnie nadawał się do wykorzystania w Bluetooth,

Bluetooth – historia powstania 1998 A.D. Rolą tej grupy było opracowanie i ustandaryzowanie nowej technologii, W skład grupy wchodziły początkowo: Ericsson, Intel, Nokia, Toshiba Obecnie członków grupy jest ponad 20,000!

Bluetooth – historia powstania 1999 A.D. – Bluetooth 1.0 Pierwsza wersja technologii, Wprowadza model tak zwanej pikosieci (jedno urządzenie MASTER obsługujące kilka urządzeń slave), Ustanowiono trzy rodzaje mocy nadajników (lepszy dobór modułów do zastosowań) Została zdefiniowana warstwa sprzętowa oraz pierwsze profile wspieranych urządzeń.

Bluetooth – pikosieci Piconet 1 + Piconet 2 = Scatternet Bezpośrednia Komunikacja między urządzeniem Slave i slave nie jest możliwa Możliwa jest za to komunikacja między pikosieciami za pomocą urządzeń bridge – slave (slave obecne w wielu pikosieciach)

Bluetooth – podział urządzeń ze względu na moc Level Power (mW) Theoretical Range (meters) 1 100 2 2,5 10 3 Najpopularniejszy jest Level 2

Bluetooth – warstwa sprzętowa Warstwa radiowa Warstwa ta odpowiedzialna jest za transport danych od urządzenia master do slave i vice versa. Jest to system o małym poborze mocy, działający w zależności od klasy na różnych zasięgach, operujący w paśmie ISM 2,4 GHz. Pasmo jest podzielone na 79 kanałów, po 1MHz każdy. System wykorzystuje modulacje FSK (Frequency Shift Keying), Baseband layer Warstwa ta jest zbliżona do podwarstwy MAC modelu OSI. Upakowuje ona luźne bity w ramki. L2CAP - trzy główne funkcje: przyjmuje pakiety o maksymalnym rozmiarze do 64 KB od wyższych warstw i dzieli je na ramki w celu transmisji. Na końcu ramki są ponownie składane w całość. zajmuje się multipleksacją i demultipleksacją złożonych pakietów. Gdy pakiet jest składany w całość, warstwa L2CAP określa, któremu protokołowi warstwy wyższej go przekazać, np. do RFcomm lub telephony. zajmuje się wymaganiami na jakość usługi, zarówno podczas zestawiania połączenia oraz podczas realizacji usługi. RFCOMM – emulacja portu szeregowego, używany przez wiele mechanizmów związanych z różnymi profilami (OBEX, PPP, komendy AT) SDP – Service Discovery Protocol

Bluetooth – przykład ramki (pakietu) Access Code - identyfikuje mastera, tak aby slave znajdujący się w zasięgu dwóch urządzeń master mógł określić, do którego odbywa się transmisja. Header (18 bitów powtarzanych 3 razy): Pole adres nagłówka identyfikuje jedno z ośmiu aktywnych urządzeń, dla którego przeznaczona jest ramka. Pole typ określa typ ramki (ACL, SCO, pool albo null), rodzaj korekcji błędów używany w polu danych oraz liczbę slotów w ramce. Pole Flow jest ustawiane przez slave, gdy jego bufory są pełne i nie może on przyjąć więcej danych. Bit Acknowledgement jest potwierdzeniem transmisji. Bit Sequence jest używany w celu numeracji ramek aby wykryć retransmisje. Ostatnie 8 bitów to suma kontrolna. 18 bitów nagłówka są powtarzane trzy razy dając w efekcie nagłówek 54 bitowy. Po stronie odbiorczej prymitywny układ sprawdza wszystkie trzy kopie każdego bitu. Jeśli wszystkie są takie same, wówczas bit jest zaakceptowany. Jeśli nie, to jeżeli otrzymano dwa zera i jedną jedynkę, wartość końcowa jest zerem, jeśli zaś dwie jedynki i jedno zero, to jedynka.

Bluetooth – profile urządzeń Jest to nic innego jak zestaw połączeń oraz ustawień udostępniany przez urządzenie, za pomocą którego realizowana jest pewna funkcjonalność określana przez standard. Aby profil mógł być używany zarówno master, jak i slave muszą go wspierać! http://en.wikipedia.org/wiki/List_of_Bluetooth_profiles -> przykłady profilów

Bluetooth – profile urządzeń A teraz pytanie – w jaki sposób określić, czy dany profil jest wspierany przez urządzenie?

Bluetooth – UUID universally unique identifier (UUID) – To 128 bitowy numer pozwalający na jednoznaczne określenie serwisów udostępnianych przez urządzenie. Bluetooth SIG określił UUID dla poszczególnych profilów. Bazowy UUID to 00000000-0000-1000-8000-00805F9B34FB, do którego aby określić usługę należy dodać 16 bitowy numer (short UUID). https://www.bluetooth.org/en-us/specification/assigned-numbers/service-discovery -> lista UUID określających usługi poszczególnych profilów Bluetooth.

JSR-82 - standard Wrzesień, 2000 A.D. – zgłoszenie JSR-82 Marzec, 2002 A.D. – pierwsza oficjalna wersja JSR-82

JSR-82 - standard Główne zastosowanie – oczywiście wszechobecna wtedy Java ME, Wsparcie dla wersji 1.2 Bluetooth (niestety – nie są wspierane profile audio oraz komendy AT), Ale – trafił też do Java SE 1.1! Całość opiera się na udostepnieniu pewnych klas bazowych oraz interfejsów – w wypadku chęci wykorzystania należy zaimplementować własną logikę (niestety – brak jest referencyjnej implementacji SUN/Oracle…) https://docs.oracle.com/javame/config/cldc/opt-pkgs/api/bluetooth/jsr082/ -> JSR-82 javadoc http://www.oracle.com/technetwork/articles/javame/index-156193.html -> opis działania

JSR-82 - standard A teraz pytanie – skoro JVM gwarantuje, że kod nie dostanie się do urządzeń w sposób bezpośredni, to jak mamy dostać się do modułów Bluetooth na naszych maszynach?

JSR-82 - standard Odpowiedź -> JNI (czyli Java Native Interface). Krótko mówiąc – jest to architektura pozwalająca na wykonywanie z poziomu kodu Javy metod napisanych w „czystym” C/C++ (coś jak „wstawki” assemblera w kodzie C/C++, tylko bardziej skomplikowane w użyciu). W wypadku bluetooth’a należy się w jakiś sposób dostać do funkcji systemu operacyjnego, które odpowiadają za obsługę urządzeń.

BlueCove – implementacja JSR-82 Bluecove jest jedyną (przynajmniej znaną mi…) biblioteką Javy, która dość dobrze wspiera najpopularniejsze systemy operacyjne (Windows/MAC OS X/Linux) będąc przy tym oparta na licencji GPL. Minus – nie jest praktycznie rozwijana… . http://bluecove.org/ http://code.google.com/p/bluecove/ http://bluecove.googlecode.com/svn/trunk/ http://www.bluecove.org/bluecove/apidocs/index.html

BlueCove – możliwości Zgodnie z wytycznymi standardu JSR-82 Bluecove udostępnia następujące funkcjonalności: Zarządzanie lokalnymi urządzeniami Bluetooth, Wyszukiwanie zdalnych urządzeń Bluetooth, Pobieranie informacji o serwisach udostępnianych przez zdalne urządzenia, Nawiązywanie i kończenie połączeń ze zdalnymi urządzeniami Bluetooth, Przekazywanie danych między połączonymi ze sobą urządzeniami, Tworzenie i udostępnianie serwisów widocznych dla innych urządzeń.

BlueCove – Zarządzanie lokalnymi urządzeniami (LocalDevice) DEMO1

BlueCove – Wykrywanie dostępnych urządzeń (DiscoveryAgent/DiscoveryListener)

BlueCove – Wykrywanie dostępnych urządzeń (DiscoveryAgent/DiscoveryListener) DEMO2

BlueCove – Wykrywanie dostępnych profilów Za wykrywanie dostępnych serwisów również odpowiada DiscoveryListener, Metoda servicesDiscovered() będzie zawierała tablicę obiektów klasy ServiceRecord, Każdy obiekt jest reprezentacją jednego serwisu jaki jest udostępniany przez urządzenie z którym chcemy się połączyć, Tak naprawdę ogranicza się on do listy parametrów, które służą do zestawienia połączenia z danym serwisem. DEMO3

BlueCove – Tworzenie własnych serwisów Nic nie stoi na przeszkodzie, żeby zaimplementować własny serwis, który będzie udostępniany dla innych urządzeń. Wystarczy tylko pamiętać o kilku rzeczach: Serwis – jako master – odpowiada za nasłuchiwanie próśb połączeń przychodzących oraz ich ewentualną akceptację, W związku z tym klasa realizująca serwis MUSI albo dziedziczyć po klasie Thread albo implementować interfejs Runnable (Zagadka – dlaczego ?), Należy brać pod uwagę z jakiego protokołu będziemy korzystać (trochę inaczej wyglądają serwisy dla RFCOMM a inaczej te bazujące na OBEX Push). DEMO Omni phone connect (Obex i message)

BlueCove – Nawiązywanie połączenia ze zdalnymi serwisami Nawiązywanie połączenia z serwisem nie różni się zbytnio od udostępniania połączenia przez serwis . DEMO Omni phone connect (Obexclient i messageclient)

Materiały dodatkowe http://www.dawidurbanski.pl/public/download/projekty/bluepad/JSR82-spec_1.1.1.pdf https://sbranski@bitbucket.org/sbranski/omniphoneconnector.git DEMO Omni phone connect (Obexclient i messageclient)

Pytania ?

DZIĘKUJĘ ZA UWAGĘ