BlueTooth探索系列（一）---JSR082API框架剪影

2019-11-18 16:19:47

字體：大中小

來源：轉載

供稿：網友

BlueTooth探索系列（一）---JSR082 API框架剪影
作者cleverpig

版權申明:可以自由轉載, 轉載請保留下面的作者信息:
作者 cleverpig(http://www.matrix.org.cn/blog/cleverpig)
關鍵詞: 藍牙,jsr,j2me,BlueTooth

一、JSR082 API框架：

1.api分類：
JSR82的API從功能上分為3大類：
1).發現：包括設備/服務發現，服務注冊；
2).通訊：包括建立設備之間的連接、使用這些連接；
3).設備管理：可以負責管理和控制連接。
所以這3類的關系主要是：設備管理-(管理)->通訊-(實現)->發現。

2.開發包劃分：
1).javax.bluetooth:提供實現藍牙功能的API。
2).javax.obex:提供無線上OBject EXchange的API。
這兩個包是各自獨立的，互相沒有依賴關系。但是他們都依賴javax.microedition.io包。

3.midp與bluetoothapi的關系：
1).CLDC：連接受限制設備配置，即KVM，提供了基本的java語法安全驗證和sandbox的安全功能。但是由于設備的處理能力有限，這里的驗證只是通過預驗證實現的，即把驗證的工作放在了計算機上，而不是j2se中的編譯和類裝載時的安全驗證。
只包含了java.lang、java.io、java.util這三個功能有限的包。
2).MIDP：移動信息設備框架，位于CLDC的上層，對CLDC的基本功能進行擴展。提供了網絡和多媒體、存儲功能。
3).Bluetooth API：藍牙應用程序接口。與MIDP平級，但獨立于MIDP，可與MIDP或CLDC共存。

4.藍牙控制中心(bcc)：
實現BluetoothAPI的藍牙設備，允許多個應用同時執行，這就需要BCC來避免一個應用與其它應用發生沖突。BBC具有允許用戶或者OEM在藍牙堆棧中定義某個配置的指定值，并解決由使用藍牙API的應用所造成的沖突請求。
所以BBC是本地藍牙設備設置的核心授權者，它的細節留給了實現：它可能是廠商提供的一個使用一個單獨的API或者一組簡單的配置本地應用程序，不能被使用者修改。

下面談一下BBC與安全模式的關系：
從最基本的層面來看，BCC定義設備相關的安全設置。例如，BCC控制虛擬機中一個棧所使用的安全模式，維護著信任設備的列表。這個API允許應用某個應用指定它的安全要求：認證、加密、授權。JSR82實現了與BBC接口，來對所有應用的安全要求作出公斷。

BCC在API中不是一個類也不是一個接口，但它是JSR82這個規范安全框架的重要部分。藍牙無線技術的Java API需要BCC才能完成對程序的安全保證。BBC是依賴實現的，它只是可能用java開發的，具體的情況按照移動設備生產廠商不同而定。

BCC的特點：
BCC必須提供以下功能的API實現：
1).設備的基本設置，包括在藍牙規范中定義的安全模式；
2).一個本地設備已知的遠端藍牙設備（并不必要為鄰近的藍牙設備）列表；
3).一個本地設備信任的遠端藍牙設備（并不必要為鄰近的藍牙設備）列表；
4).一種嘗試無線連接兩個設備的機制；
5).一種提供連接授權的機制。
以上這些信息只能被BCC所改變。

BCC可以提供，但是不被限制的行為：
1).設置本地設備的藍牙設備名字；
2).設置基帶層的超時；
3).檢測可連接/可發現模式如何被設置；
4).重置本地設備；
5).枚舉本地設備上的服務。

5.設備屬性：
一些java技術適用的藍牙產品需要根據產品和市場的需要進行不同的配置。所以設備屬性API便應運而生了。這個定義了可以通過調用LocalDevice.getPRoperty()方法而返回的附加設備屬性，如設備版本、MTU最大值等。這些屬性既提供了藍牙設備的附加信息而且定義了可被應用替換掉的限制。這些“String”類型的屬性如果沒有被定義或者未知，那么其屬性值為null。

這里需要解釋的是Page scan、Page、Inquiry、Inquiry scan。
這些屬性與藍牙設備無線連接過程密切相關：
Inquiry：首先主（Master）設備使用GIAC或DIAC查詢周圍的藍牙設備；
Inquiry Scan：同時工作在副（Slave）設備模式下的藍牙設備偵聽Inquiry；
Inquiry Response：如果副設備接收到來自主設備的Inquiry，它將發送自己的設備地址和時鐘信息給主設備；
Page Scan：在發送Inquiry Response后副設備將進入偵聽從主設備發來的廣播信息（Page message）的狀態；
Page：主設備收到Inquiry Response后發現了周圍的藍牙設備后，廣播建立連接所需要的信息；
Slave Response：處于監聽狀態的副設備收到廣播信息后，將自己的設備訪問代碼回應給主設備；
Master Response：主設備收到Slave Response后將傳輸主設備的時鐘和設備地址、設備類型回應給副設備；
Connection State：在副設備接收到Master Response后，雙方就進入了連接狀態。

6.c/s模式：
一個藍牙服務是一個類似server的應用，它提供了client設備上不具備的功能。比如打印服務就是一個藍牙服務的例子。開發者可以在藍牙框架之上自己定義自己的藍牙服務應用，并通過定義一個描述服務信息的服務記錄，并將該服務記錄添加到服務發現數據庫（SDDB），提供給遠程設備使用。
在注冊服務記錄后，server應用程序等待client開始與它的交互、并訪問服務。而另一方面，client和server程序建立藍牙連接，進行它們之間的交互。
從某個角度看，server應用好像超出了藍牙規范的范疇，那樣的話，就像藍牙發展的前期多個廠商實現各自的藍牙協議堆棧，沒有要求標準化以確保不同藍牙設備之間的互通性一樣。那一定是一場災難。不過，一套標準化的API的出臺將改變這一種混沌的局面。
這套API將server應用、client應用、藍牙堆棧三者的責任分離開來：

server應用的責任：
1).建立表述應用提供的服務的服務記錄（service record）;
2).添加服務記錄到server的SDDB，使client能夠使用之;
3).注冊在與client連接中使用藍牙安全策略;
4).接收來自client對服務的請求;
5).當服務記錄的特性改變時，即使更新server的SDDB中的服務記錄;
6).當服務失效時，刪除或者禁用server的SDDB中的服務記錄.

client應用的責任：
1).使用服務發現協議(SDP)查詢遠端設備的SDDB;
2).注冊在與server連接中使用的藍牙安全策略;
3).開始連接提供服務的server;
4).可選的，輪詢server的SDDB以確定服務是否改變或者失效.

藍牙協議堆棧提供給本地藍牙server應用的特性：
1).一個允許server添加、更新、刪除它自己的服務記錄的服務記錄倉庫;
2).給每個服務記錄賦予一個唯一的服務記錄句柄;
3).建立與client的邏輯連接.

藍牙協議堆棧提供給遠端執行服務發現的client應用的特性：
1).查詢并接收保存在server的SDDB中的服務記錄;
2).建立與server的邏輯連接.進入討論組討論。

（出處：http://m.survivalescaperooms.com）

上一篇：KVM簡介和編譯

下一篇：KVM的擴展