rfcomm協議提供了與tcp大致相同的服務和可靠性保證。儘管規範明確地宣告它是為模擬rs-232串列埠而設計的(使製造商更容易向其現有串列埠裝置新增藍芽功能)，但在許多與tcp相同的場景中使用它非常簡單。
通常，使用tcp的應用程式關心的是擁有乙個點對點連線，在這個連線上它們可以可靠地交換資料流。如果資料的一部分不能在固定的時間限制內交付，則連線將終止並交付錯誤。rfcomm與它的各種串列埠模擬屬性(在大多數情況下，這些屬性與網路程式設計師無關)一起提供了與tcp相同的主要屬性。
從網路程式設計師的角度來看，tcp和rfcomm之間的最大區別是埠號的選擇。tcp在一台機器上最多支援65535個開放埠，而rfcomm只允許30個。這對如何為伺服器應用程式選擇埠號有很大的影響，我們將很快對此進行討論。
通常用於每個資料報的可靠傳遞不是至關重要的情況，有時還用於避免tcp引起的額外開銷。特別地，選擇udp是為了它的最佳努力，簡單的資料報語義。這些都是l2cap作為通訊協議所滿足的相同的標準。
預設情況下，l2cap提供面向連線的協議，該協議可靠地傳送固定最大長度的各個資料報。 l2cap可以完全自定義，因此可以配置為具有不同級別的可靠性。 為了提供這項服務，基於l2cap的傳輸協議採用了傳輸/確認方案，在該方案中，未確認的資料報被重新傳輸。 應用程式可以使用三種策略：
雖然藍芽允許應用程式使用最佳努力通訊而不是可靠通訊，但有幾點需要注意。其原因是，調整到另乙個裝置的單個l2cap連線的傳遞語義會影響到到該裝置的所有l2cap連線。如果乙個程式調整到另乙個裝置的l2cap連線的傳遞語義，它應該注意確保沒有到該裝置的其他l2cap連線。此外，由於rfcomm使用l2cap作為傳輸，因此到該裝置的所有rfcomm連線也會受到影響.
除了放寬l2cap的傳遞語義的限制外，當應用程式不需要rfcomm的開銷和基於流的特性時，它可以作為一種合適的傳輸協議，並且可以在許多使用udp的相同情況下使用。
requirement
internet
bluetooth
reliable, streams-based
tcprfcomm
reliable, datagram
tcprfcomm or l2cap with infinite retransmit
best-effort, datagram
udpl2cap (0-1279 ms retransmit)
tips一旦知道了數字位址和傳輸協議，弄清如何與遠端計算機進行通訊的第二部分是選擇埠號。 幾乎所有常用的internet傳輸協議都是以埠號的概念設計的，因此同一主機上的多個應用程式可以同時使用傳輸協議。 藍芽也不例外，但使用的術語略有不同。 在l2cap中，埠稱為協議服務多路復用器，並且可以採用1到32767之間的奇數值。在rfcomm中，可以使用通道1-30。 除了這些差異之外，協議服務多路復用器和通道都達到與埠在tcp / ip中相同的目的。 與rfcomm不同，l2cap具有一定範圍的保留埠號（1-1023），這些埠號不用於自定義應用程式和協議。 表2-2中彙總了此資訊。 在本文件的其餘部分中，為清楚起見，使用埠一詞代替協議服務多路復用器和通道。
table 2-2
protocol
terminology
reserved/well-known ports
dynamically assigned ports
tcpport
1-1024
1025-65535
u***ort
1-1024
1025-65535
rfcomm
channel
none
1-30
l2cap
psmodd numbered 1-4095
odd numbered 4097 - 32765
在internet程式設計中，伺服器應用程式通常使用眾所周知的埠號，這些埠號是在設計時選擇並同意的。 客戶端應用程式將使用相同的知名埠號連線到伺服器。 這種方法的主要缺點是無法執行兩個使用相同埠號的伺服器應用程式。 由於tcp / ip相對較年輕，並且有大量可用的埠號可供選擇，因此這尚未成為乙個嚴重的問題。
但是，藍芽傳輸協議的可用埠號要少得多，這意味著我們不能在設計時選擇任意的埠號。雖然這個問題對於l2cap來說沒有那麼嚴重，l2cap有大約15,000個未保留埠號，但rfcomm只有30個不同的埠號。這樣做的結果是，只有7個伺服器應用程式發生埠號衝突的機率超過50%。在這種情況下，應用程式設計人員顯然不應該任意選擇埠號。藍芽對這個問題的回答是服務發現協議。
藍芽方法不是在應用程式設計時商定要使用的埠，而是在執行時分配埠，並遵循發布-訂閱模型。主機操作乙個伺服器應用程式，稱為sdp伺服器，它使用少數l2cap保留埠號之一。其他伺服器應用程式在執行時動態分配埠號，並向sdp伺服器註冊它們自己和它們提供的服務(以及分配給它們的埠號)的描述。然後，客戶端應用程式將查詢特定a上的sdp伺服器(使用定義良好的埠號)。
這就提出了乙個問題，客戶如何知道哪一種描述是他們正在尋找的。在藍芽中做到這一點的標準方法是在設計時分配乙個128位的數字，稱為通用唯一識別符號(uuid)。遵循選擇該編號的標準方法，可以保證從遵循相同方法的其他人所選擇的uuid中選擇唯一的uuid。因此，使用相同uuid設計的客戶機和伺服器應用程式可以將這個數字作為搜尋詞提供給sdp伺服器。
與rfcomm和l2cap一樣，此處僅描述了sdp的一小部分-與網路程式設計師最相關的那些部分。 使用sdp的其他方式包括描述伺服器使用的傳輸協議，提供資訊（例如對提供的服務的人可讀描述以及提供服務的人）以及在uuid以外的字段上進行搜尋（例如 服務名稱。 值得一提的另一點是，建立藍芽應用程式甚至不需要sdp。 完全有可能恢復到在設計時分配埠號並希望避免埠衝突的tcp / ip方式，這通常可以節省一些時間。 在電腦科學實驗室等受控環境中，這是相當合理的。 但是，最終，要建立可在大多數情況下執行的可攜式應用程式，該應用程式應使用動態分配的埠和sdp。
金桔藍芽閘道器藍芽連線協議說明
引數說明 字段描述 cmd命令型別，固定為setblelink type mac裝置的mac位址 stationid 用哪個閘道器進行連線 type 連線的型別名，就是剛剛儲存的test2 下發連線後，基站會反饋此次下發藍芽連線的執行結果，通過推送介面推送 注意下發命令通過http介面的，依然會通過...
藍芽的OBEX協議
1.概述 obex為object exchange，用於在藍芽裝置間傳資料物件，於紅外定義的協議，後被藍芽採用。obex在藍芽協議層中的位置如下圖 在之前的obex版本中，obex是通過rfcomm掛在l2cap上的 obex定義了object model來進行資料的交換，形式為request re...
藍芽的HFP協議
hfp協議 hands free profile 讓藍芽裝置可以控制 比如接聽 結束通話 拒接 語音撥號等，拒接 語音撥號要視 藍芽耳機 及 是否支援。1，hfp定義了音訊閘道器 ag 和擴音元件 hf 兩個角色，音訊閘道器 ag 該裝置為音訊 特別是手機 的輸入 輸出閘道器。擴音元件 hf 該裝置...