BlueTooth探索系列（三）－－-发现服务框架(续)

核心提示：BlueTooth探索系列（三）---发现服务框架(续)作者cleverpig可以自由转载, 转载请保留下面的作者信息:作者 http://www.matrix.org.cn/blog/cleverpig(http://www.matrix.org.cn/blog/cleverpig)2.SDP概貌1).sdp框架的堆

BlueTooth探索系列（三）---发现服务框架(续)
作者cleverpig

可以自由转载, 转载请保留下面的作者信息:
作者 http://www.matrix.org.cn/blog/cleverpig(http://www.matrix.org.cn/blog/cleverpig)

2.SDP概貌

1).sdp框架的堆栈：



上图显示了蓝牙协议和使用SDP的应用实例。

如图中，SrvDscApp这个服务发现用户应用位于本地设备LocDev上，通过与蓝牙SDP客户端的接口，发送服务查询请求并接收从位于远端设备RemDevs上的SDP服务器的服务查询响应。SDP使用了面向连接的L2CAP协议来传输服务，这种L2CAP协议使用基带异步无连接（ACL）来实现最终装载/传输SDP的PDU（协议数据单元）。
服务发现过程以与发现设备过程密切相关，发现设备过程又与执行设备查询和设备捆绑的过程密切相关。这样，这个SrvDscApp应用通过使用BT_module_Cntrl实例与基带进行接口，而用BT_module_Cntrl实例在进入查询模式的操作时负责指挥蓝牙模块。

注：BT_module_Cntrl可以是蓝牙协议堆栈实现的一部分或者是SrvDscApp应用的一个低级部分。正因为这样，也没有关于任何特定协议堆栈或者SrvDscApp应用实现被完成的假设，BT_module_Cntrl实例代表着一个与SrvDscApp分离的逻辑实体，它既不是SrvDscApp的一部分，也不是协议堆栈的部件或者任何相应的代码片断。
服务记录数据库在上图中显示在SDP server的右侧，它是一个逻辑实体，工作起来就像服务发现的相关信息的仓库，可被client用来查找特定服务，可被server用来发布服务。

2).配置与角色：

以下角色被定义在SDP框架中：
本地设备（LocDev）：本地设备是一个发起服务发现过程的设备。它必须至少包含蓝牙SDP框架的客户端部分：被用户用来发起发现服务过程的服务发现应用（SrvDscApp），显示发现结果的显示功能。

远程设备（RemDev）：远程设备是一种参与服务发现过程，对来自本地设备LocDev的服务查询请求作出回应。它必须包含蓝牙SDP框架中的服务器部分：即包含一个服务记录数据库，用来组成对服务发现请求的回应部分。

赋予一个设备的LocDev或者RemDev角色不是永久的也不是唯一的。某个RemDev可能像SDP客户端那样安装了SrvDscApp，而某个LocDev也可能有一个SDP Server。对于一个安装了SrcDscApp、SDP客户端、SDP Server的设备，这个设备的角色赋值是由每次的SDP会话过程决定的。因此，一个设备可以在一个特定的SDP会话中担任LocDev角色，也可能在另一次SDP会话中担任RemDev角色。由上图看出，一个没有UI的设备，不能接收用户输入并显示服务查询的结果，那么这个设备就不被看作是LocDev的候选者。但无论如何，即使这样一个设备不被看作是一个LocDev的候选者，如果运行在这个设备上的应用需要执行服务发现会话时，在下面章节的过程描述仍能应用。



上图是一个典型的服务发现结构。图中notebook作为本地设备正在查询周边的远程设备上的服务。

3)用户需求和使用场所：

本框架涉及的用途如下：
A.通过服务类查询服务；
B.通过服务属性查询服务；
C.浏览服务。

前面的两个用途是用在寻找已知的某个特定服务时的，例如用户要查找A服务或者具有B和C特点的A服务是否有效；而第三类用途则适用于通用的服务查询，例如在用户的手持蓝牙设备周边查找那些服务可用时。上面的例子中本框架的使用依赖于支持蓝牙协议的用户应用程序—SrvDscApp，这个应用在一个LocDev设备中通过与SDP协议接口来定位服务。从这个层面看，本框架与其它框架具有独到之处：SDP框架是通过一个描述与某个特定蓝牙协议接口的应用实现开发者设计的目标—最大的满足最终用户需要。

4)sdp框架基础：

在两个嵌入蓝牙的设备互相通讯之前必须经过以下过程：
A.设备需要加电和初始化。初始化过程可能需要为建立蓝牙链路和设备授权和数据加密提供一个PIN（个人标识号码）。
B.一个蓝牙链路被建立后，有一个设备发现的过程：主设备首先通过查询处理发现其它的设备的BD_ADDR，而被查询的设备则将自己所拥有的服务告知主设备。然而把LocDev设备当作主设备，而RemDev设备作为从设备的想法是看似很自然的。但这点并没有被本框架所要求。在本文档中提供的服务发现过程中，在同一个微型网络（很小的网络，也称为piconet）中任意一个设备都可能成为主设备或者从设备。而且，在这个微型网络中的一个从设备也可能在另一个微型网络中发起服务发现，即成为那个微型网络中的主设备。这样就造成了同一设备的复用冲突问题，在这种情况下，这个从设备将告知原网络中的主设备：本设备不可用（这个从设备有可能进入保持可操作模式）一段时间，当然。原网络中的主设备不能再作为另一个新的微型网络的主设备了，因为每个微型网络由这个网络中的唯一主设备的BD_ADDR来标识。

本框架不要求必须使用授权或者加密。如果授权或者加密被某个设备所调用，则服务发现将只在这些需要授权或者加密的设备上传递授权或者加密安全保障，从而加强彼此之间的数据安全。换一个说话，只有在蓝牙链路上安全限制已经存在时才被称为SDP事务的安全限制。

5）一致性保证：

如果本框架的一致性被公布，则所有在本框架中被标识为强制性的设备性能都应该以某种特定的方式支持。同样这个规则也适用于所有在本框架中被标识为强制性的可选的和有条件的性能。所有在SDP框架中强制性的性能指标、可选的和有条件的性能指标都将作为蓝牙产品认证体系中的被验证的主题。进入讨论组讨论。

（出处：http://www.cncms.com）