传统蓝牙SDP协议详细介绍

零.概述

主要介绍下蓝牙协议栈服务发现协议（SDP）协议说明以及交互封包流程的介绍

一. 声明

本专栏文章我们会以连载的方式持续更新，本专栏计划更新内容如下：

第一篇:蓝牙综合介绍 ，主要介绍蓝牙的一些概念，产生背景，发展轨迹，市面蓝牙介绍，以及蓝牙开发板介绍。

第二篇:Transport层介绍,主要介绍蓝牙协议栈跟蓝牙芯片之前的硬件传输协议,比如基于UART的H4,H5,BCSP，基于USB的H2等

第三篇:传统蓝牙controller介绍，主要介绍传统蓝牙芯片的介绍，包括射频层（RF），基带层（baseband），链路管理层（LMP）等

第四篇:传统蓝牙host介绍，主要介绍传统蓝牙的协议栈，比如HCI,L2CAP,SDP,RFCOMM,HFP,SPP,HID,AVDTP,AVCTP,A2DP,AVRCP,OBEX,PBAP,MAP等等一系列的协议吧。

第五篇：低功耗蓝牙controller介绍，主要介绍低功耗蓝牙芯片，包括物理层（PHY），链路层（LL）

第六篇：低功耗蓝牙host介绍，低功耗蓝牙协议栈的介绍，包括HCI,L2CAP,ATT,GATT,SM等

第七篇：蓝牙芯片介绍，主要介绍一些蓝牙芯片的初始化流程，基于HCI vendor command的扩展

第八篇：附录，主要介绍以上常用名词的介绍以及一些特殊流程的介绍等。

另外，开发板如下所示，对于想学习蓝牙协议栈的最好人手一套。以便更好的学习蓝牙协议栈，相信我，学完这一套视频你将拥有修改任何协议栈的能力（比如Linux下的bluez，Android下的bluedroid）。

------------------------------------------------------------------------------------------------------------------------------------------

CSDN学院链接（进入选择你想要学习的课程）：https://edu.csdn.net/lecturer/5352?spm=1002.2001.3001.4144

蓝牙交流扣扣群：970324688

Github代码：https://github.com/sj15712795029/bluetooth_stack

入手开发板：https://item.taobao.com/item.htm?spm=a1z10.1-c-s.w4004-22329603896.18.5aeb41f973iStr&id=622836061708

蓝牙学习目录：https://blog.csdn.net/XiaoXiaoPengBo/article/details/107727900

------------------------------------------------------------------------------------------------------------------------------------------

二. SDP协议说明

SDP 协议是一个简单的协议，它对下层传输的要求很小。它可以运行在可靠的分组传输协议上（如果是不可靠的，客户端可以在必要时使用超时和重发请求）。

SDP 使用一个请求/应答模型。在模型中，每一处理事务由请求协议数据单位（PDU）和应答协议数据单位组成。然而,请求和应答实际上都可以不按次序进行传输。

在服务搜索协议使用蓝牙 L2CAP 传输协议的特定情况下，可以在一个 L2CAP分组中传输多个 SDP PDU，在每一连接上只能发送一个这样的 L2CAP 给指定 SDP服务器。限制 SDP 发送确认分组成为流控制形式的一种。其中SDP是大端数据模式

1. 协议数据格式

其中PDU ID就是传输的消息ID，有以下值：

Transaction ID：传输消息的ID，request放可以在0x0000~0xffff之间取任意值，但是response要跟request一致，根据TID来区分是回应哪个request.

ParameterLength:后续para的长度

2. CONTINUATION STATE

它用于一次response不够把所有的Data传回去的情况。这时候需要将response分多次传输，如果一次response足够了，Continuation State为1个字节=0。

如果要分多次response，需要重新request，采用新的transaction ID和上一次resposne的Continuation State，用以下流程说明。

情况一：不需要Continuation State

A--->B 发送SDP request，transaction ID为C

B--->A 发送SDP respose，transaction ID为C。假设一次resposne可以返回所有数据，则Continuation State为1个字节=0。

情况二：需要Continuation State

A--->B 发送SDP request，transaction ID为C

B--->A 发送SDP respose，transaction ID为C。假设一次resposne不够返回所有数据，这时response携带Continuation State M

A--->B 发送SDP request，transaction ID为D(必须与C不同）,携带Continuation State M

B--->A 发送SDP respose，transaction ID为D。假设这次resposne还不够返回所有数据，这时response携带Continuation State N

A--->B 发送SDP request，transaction ID为E,携带Continuation State N

B--->A 发送SDP respose，transaction ID为E。假设一次resposne返回的是最后的一部分数据，则Continuation State为1个字节=0。

整个request-response的流程结束。

3. ERROR HANDLING

每一事务都由一个请求和一个应答 PDU 组成。通常,每种请求 PDU 类型都对应于一种应答 PDU类型。但是,如果服务器确认请求格式不正确或由于某种原因，服务器不能采用合适的 PDU类型进行应答时,该服务器将采用。SDP_ErrorResponse 协议数据单元应答。如下图所示：

其中ErrorCode有以下值：

4. SERVICESEARCH TRANSACTION

发送REQ如下:

SDP客户端生成一个SDP_SERVICE_SEARCH_REQ来定位与作为PDU的第一个参数给出的服务搜索模式匹配的服务记录。在收到此请求后，SDPserver应检查其服务记录数据库，并返回SDP_SERVICE_SEARCH_RSP，其中包含在其SDP数据库中与给定的服务搜索模式匹配的服务记录句柄，或一个适当的错误响应。

参数：

ServiceSearchPattern：一般就是需要一个数据元代表UUID

MaximumServiceRecordCount:

ContinuationState:

接受RSP如下：

接收到有效的SDP_SERVICE_SEARCH_REQ时，SDP服务器生成一个SDP_SERVICE_SEARCH_RSP。响应包含一个服务记录句柄列表，用于匹配请求中给定的服务搜索模式的服务记录句柄。如果生成了部分响应，则只应包含完整的服务记录句柄;一个服务记录句柄值不应该被多个pdu分割。

参数：

TotalServiceRecordCount:

CurrentServiceRecordCount:

ServiceRecordHandleList:

ContinuationState:

我们来看下交互流程，问询A2DP sink的service handle的动作

具体交互封包格式如下：

上图是发送SDP_SERVICE_SEARCH_REQ，我们来根据raw data来分析下，巩固下数据元以及上图封包交互,SDP RAW data为：

0x02 0x00 0x04 0x00 0x08 0x35 0x03 0x19 0x11 0x0B 0x00 0x14 0x00

其中0x02是PDU ID，也就是SDP_SERVICE_SEARCH_REQ

0x00 0x04也就是Transaction ID，也就是0x0004

0x00 0x08也就是ParameterLength，是8个byte

0x35 二进制表示为00110101b,高5bit为00110b也就是0x6

低3bit是101b，也就是0x05

也就是长度在后面1个byte中

0x03 长度为3个byte

0x19 二进制为00011001b，高5位是00011b,也就是0x03

低3位是001b，也就是0x01

代表后面的2个byte是UUID，也就是0x11,0x0B

后续的0x00, 0x14，就是这个参数MaximumServiceRecordCount，最大20

Continue是0

上图是发送SDP_SERVICE_SEARCH_RSP，我们再来根据raw data来分析下，巩固下数据元以及上图封包交互,这也是最后一次分析SDP raw data，后续的两个过程不再做分析，只截图，SDP RAW data为：

0x03 0x00 0x04 0x00 0x09 0x00 0x01 0x00 0x01 0x00 0x01 0x00 0x00 0x00

其中0x03是PDU ID，也就是SDP_SERVICE_SEARCH_RSP

0x00 0x04也就是Transaction ID，也就是0x0004,跟SDP_SERVICE_SEARCH_REQ必须一致

0x00 0x09也就是ParameterLength，是9个byte

0x00 0x01 是参数TotalServiceRecordCount，一共有一个请求UUID的service handle

0x00 0x01 是参数CurrentServiceRecordCount，也就是当前返回的是1

0x00 0x01 0x00 0x00是参数ServiceRecordHandleList，也就是0x10000

0x00 是continue

好啦，搞定，你应该对SDP的封包交互格式以及数据元有深刻理解了吧？继续开车喽

5. SERVICEATTRIBUTE TRANSACTION

发送REQ如下：

SDP客户端生成SDP_SERVICE_ATTR_REQ来从特定的服务记录中检索指定的属性值。所需服务记录的服务记录句柄和从该服务记录中检索到的所需属性id列表作为参数提供。

参数：

ServiceRecordHandle：

MaximumAttributeByteCount：

AttributeIDList:

ContinuationState:：

回应如下：

参数：

AttributeListByteCount：

AttributeList:

ContinuationState:

我们来看一个交互流程，巩固下以上的交互流程

回应如下：

这个比较麻烦，需要你们好好分析下喽，你分析明白一个，后续再麻烦的也是一通百通了。

6 .SERVICESEARCHATTRIBUTE TRANSACTION

发送REQ如下：

SDP_SERVICE_SEARCH_ATTR_REQ 事务综合 SDP_SERVICE_SEARCH_REQ和

SDP_SERVICE_ATTR_REQ 二者功能于一个请求中。作为参数，它既包含服务搜索图，又包含一张属性表，该属性表从与服务搜索图匹配的服务记录中检索。 SDP_SERVICE_SEARCH_ATTR_REQ及其应答与 SDP_ServiceSearch 和SDP_ServiceAttribute 两者相比，显得更复杂并且可能需要更多的字节。但是,使用 SDP_ServiceSearchAttributeRequest 可以减少总的 SDP 事务量,特别是当检索多条服务记录时。具体参数如下:

ServiceSearchPattern:

MaximumAttributeByteCount:

AttributeIDList:

ContinuationState:

RESPONSE如下格式：

参数:

AttributeListsByteCount:

AttributeLists:

ContinuationState:

找一个交互流程让你们体验下：

发送REQ如下：

接受RESPONSE如下：