BlueTooth探索系列(四)－－服务发现协议的用户接口与应用层

核心提示：BlueTooth探索系列（四）---服务发现协议的用户接口与应用层作者cleverpig版权说明：可以自由转载, 转载请保留下面的作者信息:作者 cleverpig(http://www.matrix.org.cn/blog/cleverpig)3.用户接口1）结对（pairing）SDP框架中没有硬性要求结对，也就

BlueTooth探索系列（四）---服务发现协议的用户接口与应用层
作者cleverpig

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

3.用户接口

1）结对（pairing）
SDP框架中没有硬性要求结对。也就是说结过程对可以发生也可能不发生。在一个LocDev设备对周围可连接的RemDev设备执行服务发现时，LocDev设备上的SrvDscApp应该负责允许优先结对或者旁路任何需要结对的设备。本框架只注重在LocDev建立一个合法且可用的基带链路连接到RemDev后执行服务发现的过程。
　　　　
2）模式选择
本框架假设在SrcDscApp的指挥下，LocDev设备应该进入查询和（或者）呼叫状态，而对其它设备开放服务（例如打印服务、网络数据获取和处理服务、PSTN网关服务）的RemDev设备应该进入查询扫描和（或者）呼叫扫描状态。而在蓝牙的链路控制（Link Control）中强制规定了LocDev应支持查询和呼叫状态，而RemDev应支持的查询扫描状态是可设置的设备策略，RemDev设备进入可发现模式后查询扫描状态将被激活。RemDev的呼叫扫描状态并没有在Link Control强制规定。

因为SrvDscApp可以对已连接的RemDev设备进行服务查询，而一个LocDev设备总是作为主设备去连接一个RemDev设备并没有强制性的规定。同样一个RemDev在不总是作为从设备出现在与一个LocDev的连接中。

4.应用层
1）服务发现应用
这里将讨论SrvDscApp的可操作性框架结构。下图展示了SrvDscApp可能的框架。


三种SrvDscApp的实现流程被显示在上图中，当然这三种还不能覆盖SrvDscApp实现的所有情况。SrvDscApp_A、SrvDscApp_B、SrvDscApp_C都实现了相同的目的，但是各自的遵循了不同的途径：

SrvDscApp_A：首先在LocDev设备上的SrvDscApp获取用户提供的服务描述信息。然后SrvDscApp通过蓝牙查询过程查找周围的设备，对于每个发现的设备，LocDev将连接它，并执行必要的链路建立过程，我们可以从GAP（Gerneric access PRofile）文档中发现更多的细节，此后查询被发现的设备上是否存在用户所要的服务。

SrvDscApp_B：首先查询设备，然后为服务查询收集用户输入的信息，

注意：设备发现可能在SrvDscApp应用启动之前就已经发生过了，但是由于没有什么能保证设备发现已经发生过，所以推荐SrvDscApp程序再进行一次设备查询。

SrvDscApp_C：在前两个实现流程中，呼叫、链路建立、服务发现都是在每个RemDev设备上有序的jinxing着。LocDev在没有完成前一个RemDev的服务查询并断开连接前不能进行下一个新的RemDev的查询。而SrvDscApp_C则不同于前两种实现，LocDev在SrvDscApp的控制下将呼叫所有的RemDev，然后建立与所有设备的链路（一次至多建立7个连接），查询在所有连接设备上的用户指定服务是否可用。

举个例子，我们把上图的SrvDscApp_A看作一个SrvDscApp，这个SrvDsvApp具有下面的特点：

SrvDscApp根据用户要求的某个特定服务查询激活蓝牙查询，来寻找周边的可连接的蓝牙设备RemDev；

当一个新的RemDev被发现后，SrvDscApp将完成服务发现并中断与这个设备的连接，尝试连接下一个RemDev；

当RemDev都被连接好后，LocDev在这个连接上进行服务发现；

当SrvDscApp执行连接时，SrvDscApp的用户具用信任模式操作和非信任模式操作的选择权：
a)只与信任的RemDev连接；
b)除了与a中描述的设备连接外，附加上与新发现的RemDev连接，而这些RemDev服务任何的信息除了提供默认的全零的PIN用于可能结对之用；
c)除了与a和b中描述的设备连接外，附加上符合用户输入的完整非零PIN的RemDev。

上面的选择决定于将在配置时的用户干预程度和用户与SrvDscApp交互、设置用户要求查询的服务的安全级别的程度。在选择a或者b时，设备之间将建立不正统（未经授权和加密）的连接，SrvDscApp将忽略这些信息不给用户任何的暗示。
　　　　
当一个LocDev执行一次服务发现查询时，它将面对下面的三种类型的RemDev：
1.信任设备：设备当前没有与LocDev连接，但是LocDev已经与它建立信任关系；
2.未知（新）设备：不可信任的设备，当前没有和LocDev连接；
3.已连接设备：已经与LocDev连接的设备。

为了发现第1或第2种RemDev，SrvDscApp需要激活蓝牙查询和（或者）呼叫进程。为了发现第3种RemDev，无论通过蓝牙查询进程这些设备是否被定为或者已经与LocDev设备连接，SrvDscApp需要访问在LocDev设备周边设备的BD_ADDR。这样BT_module_Cntr（蓝牙控制模块）应该维护一个LocDev周围设备的列表，并提供这个列表来帮助SrvDscApp工作。

2)服务基本构成体的抽象：
这部分主要描述SrvDscApp的功能性。SrvDscApp的功能性是用一套完整的定义了用户所期望的SrvDscApp框架表示的。当然，这里假设了SrvDscApp所依靠的蓝牙堆栈可以直接或者间接地实现这些服务基本构成体抽象所达到的目标。而“直接”的意思是指被定义的功能直接使用了蓝牙堆栈实现中的某个调用，“间接”是指被定义的功能使用了多个蓝牙堆栈实现中的调用来完成它的目标。服务基本构成体抽象的精确语法和语义具有平台（例如一个操作系统、一个硬件平台、笔记本、蜂眼电话等）依赖性，这些超出了SDP框架的范围。但是这些基本构成体的功能被期望对SrvDscApp完成它的任务有所帮助。下面的表格包含了一个能够支持SrvDscApp的最小服务基本构成体的集合。至于低级别的基本构成体如openSearch()或者closeSearch()等都作为上面的基本构成体的一部分没有显示在下面的表格中。蓝牙堆栈的不同实现至少应该具备这些服务基本构成体。

例如，serviceSearch()服务基本构成体同时使用了多个蓝牙堆栈中单独的操作。也就是说，一个应用程序需要一个蓝牙堆栈实现，这个堆栈被应用程序调用来完成由多个独立的操作组合体反复调用所构成的功能，所以这个由多个独立的操作组合体反复调用所构成的功能就使服务基本构成体具备了功能。即使本框架中提供的这些服务基本构成体被假设作用于一个访问物理的远程设备，而这里的“远程设备”只是一个逻辑设备，如：被查询服务记录的、提供服务的是调用这些服务基本构成体的同一个设备。一个服务基本构成体只显示下一个使用蓝牙协议以无线交换数据为结果或者与无线交换数据相关的服务基本构成体之间的关系。附加的服务基本构成体能够被想象为与单纯的本地操作（如服务注册）相关，但这些基本构成体已经超越了SDP框架的范畴。



上表为SrvDscApp所支持的服务构成体列表。

注意：每个服务构成体的调用都被看作是一次primitiveHandle。

上面的stopRule参数被用于保证一次服务查询的完美终止，它表示查询过程所花费的时间。作为一个蓝牙堆栈的实现，不能暴露这个参数，因为它提供了对所有查询终止的保证。

enumerateRemDev(.)这个服务构成体直接关系到了查询模式，而且也关系到了一个LocDev所连接的RemDev的集合。这个服务通过BT_module_Cntr导出到SrvDscApp中。它在BT_module_Cntr和基带之间激活蓝牙查询并收集查询的结果集。而且它位于BT_module_Cntr和L2CAP之间，跟踪着每一个当前被LocDev连接的RemDev。

enumerateRemDev(.)的结果被用在serviceSearch(.)中用来在被发现的设备上查询特定的服务，这个服务基本构成没有被蓝牙堆栈实现明确的提供，但它已经融入到了其它的服务基本构成中（如serviceSearch(.)）。

3）消息队列图表(message SEQUENCE CHARTS，简称MSCS)
本框架关系到三个蓝牙过程：设备发现、设备名称发现、服务发现。它们中的任意一个都不预包含另外一个；例如：为了连接一个RemDev，一个LocDev必须先发现这个设备，当然也可以询问它的设备名称。

下图罗列了本框架执行过程中所发生的关键信息交换过程。不是所有的过程都能够涉足，不是所有的设备都经过这些过程。例如如果认证不需要，下图的认证过程就不执行。如果SrvDscApp需要去查询LocDev所连接的某个特定RemDev上的服务，查询和呼叫将不执行。下图中对于每个过程都提供了其执行的条件。


SDP框架支持的蓝牙处理过程表图进入讨论组讨论。

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