主要介绍下蓝牙协议栈服务发现协议（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学院链接（进入选择你想要学习的课程）：
蓝牙交流扣扣群：970324688
Github代码：
入手开发板：
蓝牙学习目录：
------------------------------------------------------------------------------------------------------------------------------------------
SDP 协议是一个简单的协议，它对下层传输的要求很小。它可以运行在可靠的分组传输协议上（如果是不可靠的，客户端可以在必要时使用超时和重发请求）。
SDP 使用一个请求/应答模型。在模型中，每一处理事务由请求协议数据单位（PDU）和应答协议数据单位组成。然而,请求和应答实际上都可以不按次序进行传输。
在服务搜索协议使用蓝牙 L2CAP 传输协议的特定情况下，可以在一个 L2CAP分组中传输多个 SDP PDU，在每一连接上只能发送一个这样的 L2CAP 给指定 SDP服务器。限制 SDP 发送确认分组成为流控制形式的一种。其中SDP是大端数据模式
其中PDU ID就是传输的消息ID，有以下值：
Transaction ID：传输消息的ID，request放可以在0x0000~0xffff之间取任意值，但是response要跟request一致，根据TID来区分是回应哪个request.
ParameterLength:后续para的长度
它用于一次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的流程结束。
每一事务都由一个请求和一个应答 PDU 组成。通常,每种请求 PDU 类型都对应于一种应答 PDU类型。但是,如果服务器确认请求格式不正确或由于某种原因，服务器不能采用合适的 PDU类型进行应答时,该服务器将采用。SDP_ErrorResponse 协议数据单元应答。如下图所示：
其中ErrorCode有以下值：
发送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的封包交互格式以及数据元有深刻理解了吧？继续开车喽
发送REQ如下：
SDP客户端生成SDP_SERVICE_ATTR_REQ来从特定的服务记录中检索指定的属性值。所需服务记录的服务记录句柄和从该服务记录中检索到的所需属性id列表作为参数提供。
参数：
ServiceRecordHandle：
MaximumAttributeByteCount：
AttributeIDList:
ContinuationState:：
回应如下：
参数：
AttributeListByteCount：
AttributeList:
ContinuationState:
我们来看一个交互流程，巩固下以上的交互流程
回应如下：
这个比较麻烦，需要你们好好分析下喽，你分析明白一个，后续再麻烦的也是一通百通了。
发送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如下：
