传统蓝牙SDP协议详细介绍
零.概述
主要介绍下蓝牙协议栈服务发现协议（SDP）协议说明以及交互封包流程的介绍git
一. 声明
本专栏文章咱们会以连载的方式持续更新，本专栏计划更新内容以下：github
第一篇:蓝牙综合介绍 ，主要介绍蓝牙的一些概念，产生背景，发展轨迹，市面蓝牙介绍，以及蓝牙开发板介绍。数据库
第二篇: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等等一系列的协议吧。spa
第五篇：低功耗蓝牙controller介绍，主要介绍低功耗蓝牙芯片，包括物理层（PHY），链路层（LL）.net
第六篇：低功耗蓝牙host介绍，低功耗蓝牙协议栈的介绍，包括HCI,L2CAP,ATT,GATT,SM等视频
第七篇：蓝牙芯片介绍，主要介绍一些蓝牙芯片的初始化流程，基于HCI vendor command的扩展server
第八篇：附录，主要介绍以上经常使用名词的介绍以及一些特殊流程的介绍等。htm
另外，开发板以下所示，对于想学习蓝牙协议栈的最好人手一套。以便更好的学习蓝牙协议栈，相信我，学完这一套视频你将拥有修改任何协议栈的能力（好比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
蓝牙学习目录：http://www.javashuo.com/article/p-cydcgesb-nt.html
------------------------------------------------------------------------------------------------------------------------------------------
二. 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以下：