蓝牙-协议基础

RFCOMM + TCP

RFCOMM协议提供了与TCP大致相同的服务和可靠性保证。尽管规范明确地声明它是为模拟RS-232串行端口而设计的(使制造商更容易向其现有串行端口设备添加蓝牙功能)，但在许多与TCP相同的场景中使用它非常简单。
通常，使用TCP的应用程序关心的是拥有一个点对点连接，在这个连接上它们可以可靠地交换数据流。如果数据的一部分不能在固定的时间限制内交付，则连接将终止并交付错误。RFCOMM与它的各种串行端口模拟属性(在大多数情况下，这些属性与网络程序员无关)一起提供了与TCP相同的主要属性。
从网络程序员的角度来看，TCP和RFCOMM之间的最大区别是端口号的选择。TCP在一台机器上最多支持65535个开放端口，而RFCOMM只允许30个。这对如何为服务器应用程序选择端口号有很大的影响，我们将很快对此进行讨论。

L2CAP + UDPUDP

通常用于每个数据包的可靠传递不是至关重要的情况，有时还用于避免TCP引起的额外开销。特别地，选择UDP是为了它的最佳努力，简单的数据报语义。这些都是L2CAP作为通信协议所满足的相同的标准。

默认情况下，L2CAP提供面向连接的协议，该协议可靠地发送固定最大长度的各个数据报。 L2CAP可以完全自定义，因此可以配置为具有不同级别的可靠性。 为了提供这项服务，基于L2CAP的传输协议采用了传输/确认方案，在该方案中，未确认的数据包被重新传输。 应用程序可以使用三种策略：

• 永远不会重新发送
• 重新传输直到完全连接失败（默认）
• 如果在指定的时间限制(0-1279毫秒)之后数据包没有得到确认，则丢弃一个数据包并转移到排队的数据。当数据必须以及时的方式传输时，这是有用的。

虽然蓝牙允许应用程序使用最佳努力通信而不是可靠通信，但有几点需要注意。其原因是，调整到另一个设备的单个L2CAP连接的传递语义会影响到到该设备的所有L2CAP连接。如果一个程序调整到另一个设备的L2CAP连接的传递语义，它应该注意确保没有到该设备的其他L2CAP连接。此外，由于RFCOMM使用L2CAP作为传输，因此到该设备的所有RFCOMM连接也会受到影响.

除了放宽L2CAP的传递语义的限制外，当应用程序不需要RFCOMM的开销和基于流的特性时，它可以作为一种合适的传输协议，并且可以在许多使用UDP的相同情况下使用。

Requirement	Internet	Bluetooth
Reliable, streams-based	TCP	RFCOMM
Reliable, datagram	TCP	RFCOMM or L2CAP with infinite retransmit
Best-effort, datagram	UDP	L2CAP (0-1279 ms retransmit)

tips

• L2CAP规范实际上允许无连接和基于连接的通道，但是在实践中很少使用无连接通道。由于向设备发送“无连接”数据需要加入它的piconet(一个只需要在较低级别建立连接的耗时过程)，因此无连接L2CAP通道与面向连接的通道相比没有任何优势。
• 默认的最大长度是672字节，但是最多可以协商为65535字节
• 异步无连接逻辑传输

端口号和服务发现协议

一旦知道了数字地址和传输协议，弄清如何与远程计算机进行通信的第二部分是选择端口号。 几乎所有常用的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
TCP	port	1-1024	1025-65535
UDP	port	1-1024	1025-65535
RFCOMM	channel	none	1-30
L2CAP	PSM	odd 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。