1.概述
obex為object exchange，用於在藍芽裝置間傳資料物件，**於紅外定義的協議，後被藍芽採用。obex在藍芽協議層中的位置如下圖（在之前的obex版本中，obex是通過rfcomm掛在l2cap上的）：
obex定義了object model來進行資料的交換，形式為request-response。obex定義了headers來描述資料，結構如下：
1byte
n byte
由hi和hv兩部分組成。hi的最高兩位表示這個header的編碼形式，低6位表示header的型別，hv表示資料實體。
高兩位的編碼如下：
0x00和0x40兩種後面會跟上2位元組的length（length prefixed），表示的是整個header的長度，包括hi和hv。
低6位的定義型別如下：
提一下end-of-body，用來表示資料傳輸的最後乙個data chunk。
3.request和response
在obex的規定中，client和server通過request-response的形式來進行對話，交換的資料報含在這兩種包中，分別定義如下：
(1)request format
引數opcode表示該request的型別，length表示整個request的位元組數，最後跟著的是第2節中定義的各種headers。
opcode有如下幾種形式：
opcode的最高位稱為final bit，用來表示某乙個request的最後乙個packrt，這個在下面的例子中說明。
引數response code表示該response的型別，length表示整個request的位元組數，最後跟著的是第2節中定義的各種headers。
response code的最高位稱為final bit，用來表示可以繼續傳輸資料，這個在下面的例子中說明，其有如下幾種：
4.幾種常見的操作及其例項
乙個connect的例項：
可以看出，rquest中帶了兩個header，分別是count和length。
乙個put的例項：
在這個例子中，可以看出opcode和response code的final bit的作用。在client端，用put命令傳送資料時，如果不是最後乙個packet，final bit都是為0，最後乙個packet時時置為1；在server端， 當接受到final bit為0的client端的request時，response的final bit總是置為1，表示可以繼續傳輸，當收到最後乙個request時，發現client發過來的request置為1了，這時候response的final bit變為0。
5，總結
obex協議在藍芽中用於物件交換，**於紅外的obex協議。obex協議規定client與server之間以request-response的形式進行對話，有request和response兩種資料形式。常用的obex的操作位connect,disconnect,put,
get等，操作十分簡單。
藍芽的HFP協議
hfp協議 hands free profile 讓藍芽裝置可以控制 比如接聽 結束通話 拒接 語音撥號等，拒接 語音撥號要視 藍芽耳機 及 是否支援。1，hfp定義了音訊閘道器 ag 和擴音元件 hf 兩個角色，音訊閘道器 ag 該裝置為音訊 特別是手機 的輸入 輸出閘道器。擴音元件 hf 該裝置...
藍芽 協議基礎
rfcomm協議提供了與tcp大致相同的服務和可靠性保證。儘管規範明確地宣告它是為模擬rs 232串列埠而設計的 使製造商更容易向其現有串列埠裝置新增藍芽功能 但在許多與tcp相同的場景中使用它非常簡單。通常，使用tcp的應用程式關心的是擁有乙個點對點連線，在這個連線上它們可以可靠地交換資料流。如果...
藍芽協議4 0 4 1 4 2的比較
sig在2010年發布了4.0的specification，2013年發布了4.1的specification，一年以後，在2014年又發布了4.2的specification，specification的調整很快。從4.0版本起，革命性的加入了ble協議部分，同時將2.1 edr和3.0 hs全都...