obex
obex
OBEX協議定義了一種柔性的概念——objects。也即是對象。這些對象可以包括文件，診斷信息，電子商務卡片，銀行的存款等等。Objects在這裡沒有高級的技術含義，而是視你的應用而定。
OBEX協議小到可作“命令和控制”功能，例如對電視機，錄像機等的操作。大到可以做很複雜的操作，例如資料庫的事務處理和同步。
OBEX能夠具有以下幾個特點：
1、友好的應用——可實現快速開發。
2、緊縮——可用在資源有限的小型設備上。
3、跨平台
4、柔性的數據支持。
5、方便的作為其他Internet傳輸協議的上層協議。
6、可擴展性——提供了對未來需求的擴充支持而不影響以存在的實現。例如可擴展安全，數據壓縮等。
7、可測試可調試。
更為具體的關於OBEX的介紹請查閱IrOBEX協議。
關於Headers
對象模型回答了對象是如何在OBEX協議描述的。這個模型必須包括被傳輸的對象和對對象的描述。為了做到這點，OBEX定義了Headers的概念。
Headers的構成
Headers簡單的由和組成，簡稱為
和。
HI由一個位元組組成，指出了Header包含的內容以及它的格式。HV包含了一個或者多個位元組，其結構由HI所決定。
所有的Header都是可選的，取決於設備的類型和事務的種類。你可以使用所有的Header，或者一些，或者沒有。ID可以使Header可解析以及與傳輸順序無關，也可以使不支持的Header被忽略掉。
HI又可以分為兩部分，高2位和低6位。高2位確定了HI的編碼方式（見表二），低6位確定了HI的意義（見表三）。兩個表都是我從IrOBEX中的表摘抄並部分翻譯過來的。
表二
| HI的第8和第7位 | 意義 |
| 00(0x00) | 以Null（0x00）結尾的的Unicode文字。2個位元組的無符號整數長度前綴。 |
| 01(0x40) | Byte塊，2個位元組的無符號整數前綴。 |
| 10(0x80) | 1Byte容量。 |
| 11(0xC0) | 4Byte容量，以高位先傳輸為原則。 |
表三
| HI | Header名稱 | 描述 |
| 0xC0 | Count | 連接中用於指名對象的數量。 |
| 0x01 | Name | 對象的名字。一般為文件名。 |
| 0x42 | Type | 對象的類型。例如text,html,binary,manufacture specific |
0x44 0xC4 | Time | 時間戳。ISO 8601版本 時間戳。4Byte版本（用於兼容） |
| 0x05 | Description | 對對象的文本描述 |
| 0x46 | Target | 操作的目的服務名 |
| 0x47 | HTTP | 一個HTTP1.x頭 |
| 0x48 | Body | 對象的一部分 |
| 0x49 | End of body | 對象的最後一部分 |
| 0x4A | Who | OBEX Application標識，用於表明是否是同一個應用。 |
| 0xCB | Connection ID | 用於OBEX多路連接的標識 |
| 0x4C | App.Parameters | 擴展的應用層請求和回複信息 |
| 0x4D | Auth.Challenge | Authentication digest-challenge |
| 0x4E | Auth.Response | Authentication digest-response |
| 0x4F | Object Class | 對象的OBEX對象類 |
| 0x10 to 0x2F | Reserved | 保留 |
| 0x30 to 0x3F | User defined | 用戶自定義的。 |
關於常用Header的更詳盡的解釋，更詳盡信息請參考IrOBEX
1、Name
Name是一個用來描述對象名稱的Header，由以Null(0x00)結尾的Unicode字元串組成。例如：DEMO.TXT
2、Length
Length描述了對象的大小，由4個位元組組成。如果Length事先知道，這個Header應該被用到。這樣可以讓接受者迅速的知道需要分配多少空間，可使處理更為迅速。但這也不是必須的，有些情況下長度無法確認，但設備可以通過End-Body Header知道什麼時候結束。
3、Time
Time描述了對象的最後修改的時間。使用ISO8601格式。
本地時間格式：YYYYMMDDTHHMMSS
UTC時間格式：YYYYMMDDTHHMMSSZ
格式中的T可以方便的區分日期和時間。UTC時間使用Z作為標記。建議使用UTC時間。
4、Body、End-of-Body
Body Header由HI、一個2Byte長度的描述和整個的對象本身。End-of-Body組成和Body組成一樣，但標識了這是對象的最後一部分。如果對象本來就很小，就直接使用End-of-Body。
三、請求（Request）和回應（Response）
OBEX使用Request和Response作為最基本的操作。請求的每個Request必然有一個Response，否則可認為Request失敗。
Request由一個或多個的Packet（包）組成，每個包的結構如下表
Request數據包結構
| Byte 0 | Byte 1,2 | Byte 3 to n |
| 操作碼(opcode) | Packet Length（包長度） | Headers或請求信息 |
由於每個Request可能有多個Packet，opcode的最高位稱為Final bit。如果被設置為1，那麼說明這是Request的最後一個Packet。例如：當用PUT操作發送一個大文件時，會有幾個Packet作為一個Request。那麼只有最後一個Packet的FinalBit設置為1。
Response也由一個或多個Packet組成，每個包的結構如下表
Response數據包結構
| Byte 0 | Byte 1,2 | Byte 3 to n |
| Response Code（返回值） | Response Length（回應長度） | ResponseData回應的數據 |
同樣的ResponseCode的最高位也叫做FinalBit。ResponseData可能包含對象和Header，或者其它信息。
下表列出了了常見的opcode和responseCode，更詳盡的請參考IrOBEX 1.2文檔。
opcode
| Opcode(w/high bit set) | 定義 | 意義 |
| 0x80 * | Connect | 連接 |
| 0x81 * | Disconnect | 斷開連接 |
| 0x02(0x82) | Put | 發送一個對象 |
| 0x03(0x83) | Get | 取得一個對象 |
| 0x04(0x84) | Reserved | 保留的 |
| 0x85 * | SetPath | 設置路徑 |
| 0xFF * | Abort | 取消當前的操作 |
| 0x06到0x0F | Reserved | 作為擴展保留 |
| 0x10到0x1F | User definable | 用戶自定義的 |
*總是設置FinalBit
ResponseCode
| ResponseCode | 定義 |
| 0x10(0x90) | Continue（繼續） |
| 0x20（0xA0） | OK，Success |
| 0x40(0xC0) | Bad Request（服務端不明白Request） |
| 0x41(0xC1) | Unauthorized（未授權的） |
| 0x43(0xC3) | Fobidden（禁止——伺服器明白Request，但拒絕） |
| 0x44(0xC4) | Not Found（未找到） |
四、說明。
1、 Connect（連接）
此操作初始化會話然後設置參數。其Request格式為
| Byte 0 | Byte 1,2 | Byte 3 | Byte 4 | Byte 5,6 | Byte 7 to n |
| 0x80 | 包長度 | OBEX版本 | 標誌 | 最大OBEX包長度 | 可選Header |
註：OBEX版本現在為1.0。
Response格式為：
| Byte 0 | Byte 1,2 | Byte 3 | Byte 4 | Byte 5,6 | Byte 7 to n |
| ResponseCode | 包長度 | OBEX版本 | 標誌 | 最大OBEX包長度 | 可選Header |
對於更多關於Connect的說明請參考IrOBEX
2、 Disconnect（斷開當前會話）
此操作斷開OBEX會話。例如斷開當前FolderListing Service，然後使用Connect連接到IrMC Sync Service實現同步通訊薄等功能。
Disconnect格式為：
| Byte 0 | Bytes 1,2 | Bytes 3 to n |
| 0x81 | 包長度 | 可選Header |
成功的斷開會返回0Xa0，拒絕會返回0xD3
3、 Put操作
Put操作從客戶端發送一個對象到服務端。一般至少含有Name和Length兩個Header。對於文件而言有可能還有Date/Time Header