零.概述

本文主要介绍传统蓝牙SDP的概念，SDP在整个协议栈中的架构,SDP的UUID，服务类，以及服务类属性介绍。

服务发现协议(SDP)为应用程序提供了一种方法来发现哪些服务可用，并确定这些可用服务的特征。比如主动问询对方支持哪些蓝牙协议，或者单独问询对方蓝牙电话HFP

一. 声明

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

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

第二篇: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)为应用程序提供了一种方法来发现哪些服务可用，并确定这些可用服务的特征。比如主动问询对方支持哪些蓝牙协议，或者单独问询对方蓝牙电话HFP，在整个蓝牙中的架构如红框内：

整个SDP是基于C/S架构，主要是client发起request,server回送response,如下图：

三. SDP常用术语

1. 服务记录

服务是任何一个能够提供信息、执行动作、或代表另一实体控制资源的实体 。服务可以以软件、硬件、或硬软件混合的形式来实现。由 SDP 服务器所维护服务的所有信息都包含于一条服务记录中。该服务记录全部由一张服务属性表组成。如下图所示：

其中服务记录包括服务句柄 服务属性服务句柄是一个32位无符号整形的数字，整个sdp server中必须唯一服务属性如下小节。

2. 服务属性

服务属性用于描述某一服务的一个特征。服务属性的实例如下：

其中服务属性的格式如下：

其中属性ID是1个16位无符号整形的数字，属性值要看ID，来决定是什么格式，属性在后面介绍

总结起来，整个服务器应该包含如下结构（0条或者多条记录）：

3.UUID

UUID 是经授权可在所有时空中保持唯一的通用定位符。UUID 可以分布的方式独立创建，而且不需要指定 UUID 的中心注册机构。UUID 值长度为 128 位。

为了减少存储压力，并便于 128 位 UUID 值的转换,UUID 值域已经为了常用和注册的目的进行预先分配。在该已分配域的第一个 UUID 作为蓝牙基 UUID，具有来自蓝牙号码分配文件的值 00000000-0000-1000-7007- 00805F9B34FB。在该已分配域的 UUID 值都具有 16 位或 32 位的别名。这些别名常被称为 16 位或 32位 UUID。但每一别名实际上都代表一个 128 位 UUID 。可以通过一个简单的数学运算计算 16 位或 32 位 UUID 的全部 128 位值。

128 位值 = 16 位值 × 2^96 蓝牙基 UUID

128 位值 = 32 位值 × 2^96 蓝牙基 UUID

通过对 16 位值进行零扩展，将 16 位 UUID 转换成为 32 位 UUID 格式。另外

一个转换方法是将 16 位值加到所有位都为零的 32 位 UUID 。

注 ：可以直接对两个 16 位 UUID 或 32 位 UUID 或 128 位 UUID 进行比较,如果要对不同大小的 UUID 进行比较，短 UUID 必须在比较前转换成为长 UUID 格式。

具体协议的UUID如下，参考：

Base Universally Unique Identifier (UUID)

The Base UUID is used for calculating 128-bit UUIDs from “short UUIDs” (uuid16 and uuid32) as described in the SDP Specification. See Service Discovery Protocol (SDP) in the Bluetooth Core Specification.

NOTE: Currently all assigned short UUIDs are uuid16 types.

4. 服务类 

每一服务都是服务类的一个实例。服务类定义提供对所有包含于服务记录中属性的定义，而这些服务记录就代表一个类实例。每一属性定义将给出该属性 ID的数字值、该属性值的用法及其格式。服务记录包含服务类的专用属性，以及用于所有服务的通用属性。

每一服务类将指定一个唯一标识符 。 该服务类标识符包含于ServiceClassIDList 属性的属性值，并表示为 UUID。由于服务记录中的某些属性的格式和含义依赖于服务记录的服务类,因此 ServiceClassIDList 属性非常重要。在使用任一类指定属性之前，应检查或验证它们的值。由于服务记录的所有属性必须遵循所有的服务类,包含于 ServiceClassIDList 属性中的服务类标识符也与此有关。特别要说明的是,每一服务类都是另外一类的子类，该父类的标识符包含在 ServiceClassIDList 列表中。服务子类定义与其父类不同，子类中包含该其它子类特定的属性定义。ServiceClassIDList 属性中的服务类标识符，按照从底层类到高层类的顺序一一列出。

在定义本身是另一服务类子类的新服务类时，该新类将保留父类定义的所有属性。同时，也将定义专用于新服务类的其它属性。换句话说, 向已有服务类的某些实例添加新属性的机制将创建一个新的服务类，该服务类是已有服务类的子类。

有以下服务类，如excel

 五.特定类属性 

具体参照,如图：

我们以截图的方式给出：