CN107046537B - 一种基于DNS-SD的OCF客户端对AllJoyn服务的发现方法 - Google Patents

Abstract

本发明公开了一种基于DNS‑SD的OCF客户端对AllJoyn服务的发现方法，其通过发送符合AllJoyn服务发现机制的DNS‑SD消息去发现AllJoyn服务资源。通过本方案可以实现OCF客户端设备对AllJoyn服务资源的发现，实现了OCF协议与AllJoyn协议互联互通。

Description

一种基于DNS-SD的OCF客户端对AllJoyn服务的发现方法

技术领域

本发明涉及网络技术，具体涉及OCF客户端对AllJoyn服务的发现技术。

背景技术

AllJoyn的服务发现机制采用Next-generation Name service(NGNS)，NGNS发现协议采用了通过使用AllJoyn申请的多播地址和端口来发送基于多播的mDNS。AllJoyn服务消费端调用FindAdvertiseName()初始化NGNS消息序列，NGNS通过多播DNS发送基于DNS-SD的查询消息；NGNS使用AllJoyn申请的多播地址和端口来发送基于多播的DNS，IPv4组播地址为224.0.0.251，IPv6组播地址为FF02::FB，组播端口号为5353；任何与搜索名字匹配的服务提供端通过单播方式发送DNS-SD消息响应服务消费端。

OCF的服务发现是基于CoAP discovery机制。所有发布中的OCF设备加入“AllCoAP Nodes”多播分组，如IPv6中的FF0X::FD或监听端口“5683”。需要发现资源的OCF客户端也加入该多播分组。OCF客户端发送一个发现请求给多播分组和端口“5683”，请求的URI为/oic/res。如果OCF客户端正处在发现指定资源类型的过程中，则它应使用带有指定“rt”参数的查询指令，否则所有的OCF设备都会回复此请求。

可见，AllJoyn系统的服务发现机制和OCF的资源发现机制使用两种完全不同的发现协议，因此，AllJoyn设备与OCF设备之间无法互相发现。

发明内容

针对现有AllJoyn设备与OCF设备之间无法互相发现的问题，需要一种能够实现AllJoyn设备与OCF设备之间互相发现的方案。

为此，本发明所要解决的技术问题是提供一种基于DNS-SD的OCF客户端对AllJoyn服务的发现方法，使得AllJoyn设备与OCF设备之间可互相发现。

为了解决上述技术问题，本发明提供的基于DNS-SD的OCF客户端对AllJoyn服务的发现方法，通过发送符合AllJoyn服务发现机制的DNS-SD消息去发现AllJoyn服务资源。

在本方案中，在OCF客户端，通过OCF的资源发现接口发现AllJoyn服务资源，并将该资源生成AllJoyn标准的DNS-SD查询消息。

在本方案中，OCF客户端的资源发现接口将OCF的resource URI映射为DNS-SD消息中的TXT记录的“PATH＝{URI}”，对应于AllJoyn的对象路径；

将OCF的resourcetype映射为DNS-SD消息中TXT记录的“NAME＝{resourcetype}”，对应于AllJoyn的well-known name；

将OCF的resourceinteface映射为DNS-SD消息中TXT记录的“IF＝{resourceinterface}”，对应于AllJoyn的接口。

在本方案中，以多播的方式发送DNS-SD消息。

在本方案中，AllJoyn服务端收到DNS-SD查询消息后，进行匹配，在AllJoyn服务和OCF要发现的资源相互匹配后，返回相应的DNS-SD响应消息给OCF客户端。

在本方案中，OCF客户端在接收到DNS-SD响应消息后，进行解析得到AllJoyn服务的资源属性。

通过本方案可以实现OCF客户端设备对AllJoyn服务资源的发现，实现了OCF协议与AllJoyn协议互联互通。

附图说明

以下结合附图和具体实施方式来进一步说明本发明。

图1为本方案中DNS-SD消息的生成流程图；

图2为本方案中OCF客户端发现AllJoyn服务资源的流程图；

图3为本发明实例中OCF客户端发现AllJoyn服务资源的流程图。

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合具体图示，进一步阐述本发明。

本方案基于DNS-SD消息，有效实现OCF客户端对AllJoyn服务的发现。由OCF客户端通过发送符合AllJoyn服务发现机制的DNS-SD消息去发现AllJoyn服务资源。

为此，本方案在OCF客户端，使用OCF的资源发现接口去发现AllJoyn服务资源，此时使用的AllJoyn服务资源符合OCF标准资源定义规范，拥有resource URI，resource type等；OCF客户端的资源发现接口将该资源生成AllJoyn标准的DNS-SD查询消息，由此实现对OCF客户端设备对AllJoyn服务资源的发现。

其中，DNS-SD(DNS-Based Service Discovery)定义了一种配置DNS PTR，SRV和TXT记录的常规方法。

而AllJoyn客户端通过如下名字格式来查询某一DNS PTR记录，从而发现某一服务的所有实例：

<Service>.<Domain>。

DNS-SD响应方返回DNS SRV和DNS TXT记录，且SRV和TXT有如下的命名格式：

<Instance>.<Service>.<Domain>。

在此基础上，为生成符合AllJoyn服务发现机制的DNS-SD消息(即AllJoyn标准的DNS-SD消息)，OCF客户端发现资源接口需要提供resource URI，resource type和resourceinterface。

同时，OCF资源与AllJoyn DNS-SD消息之间采用如下的映射规则：

将OCF的resource URI映射为DNS-SD消息中的TXT记录的“PATH＝{URI}”，对应于AllJoyn的对象路径；

将OCF的resourcetype映射为DNS-SD消息中TXT记录的“NAME＝{resourcetype}”，对应于AllJoyn的well-known name；

将OCF的resourceinterface映射为DNS-SD消息中TXT记录的“IF＝{resourceinterface}”，对应于AllJoyn的接口。

据此，本方案中DNS-SD消息的生成流程如下(参见图1)：

(1)定义要发现的AllJoyn服务的ResourceURI、Resource Type和ResourceInterface，以及OCF客户端应用程序调用findResource()方法；

(2)C++SDK通过进程间通信调用底层栈的资源发现方法OCDoResource()方法；

(3)OCStack接收到待发现AllJoyn资源的参数，按照上述对应的映射规则转化封装成DNS-SD消息；

(4)调用Socket，以多播的方式发送DNS-SD消息,其中IPv4组播地址为224.0.0.251，IPv6组播地址为FF02::FB，组播端口号为5353。

基于上述的DNS-SD查询消息，OCF客户端在发送DNS-SD查询消息后，AllJoyn服务端收到该DNS-SD查询消息，如果AllJoyn服务端拥有和DNS-SD查询消息相同的well-knownname，将会返回相应的DNS-SD响应消息给OCF客户端，至此，完成OCF客户端对AllJoyn服务的发现过程。

由此，OCF客户端基于DNS-SD消息发现AllJoyn服务的流程如下(参见图2)：

(1)AllJoyn服务提供端连接AllJoyn router，注册总线对象，申请well-knownname；

(2)AllJoyn服务对象开启mDNS端口监听；

(3)OCF客户端初始化，调用OCF资源发现接口，寻找AllJoyn资源；

(4)OCStack根据发现的AllJoyn资源属性生成DNS-SD查询消息；

(5)按照mDNS多播发送DNS-SD查询消息；

(6)AllJoyn服务端收到DNS-SD查询消息，解析TXT记录，匹配对应的well-knownname和接口；

(7)AllJoyn服务和OCF要发现的资源相互匹配，AllJoyn服务端发送DNS-SD回复；

(8)OCF客户端收到DNS-SD回复，解析TXT记录，得到AllJoyn服务的资源属性，完成对AllJoyn服务资源的发现过程。

下面以资源发现的实例具体阐述OCF客户端基于DNS-SD消息对AllJoyn服务的发现过程。

首先，如下表所示，分别为AllJoyn标准服务对象和OCF标准资源进行定义：

由此，OCF客户端对AllJoyn服务的发现的整个流程如下(参见图3)：

(1)AllJoyn服务提供端注册总线对象，对象路径为：/org/freedesktop/example，接口为：org.alljoyn.example.test。

(2)AllJoyncore向AllJoyn路由申请well-known name:org.alljoyn.example。

(3)AllJoyn服务端绑定端口，开启mDNS端口监听。

(4)OCF客户端调用资源发现函数，发现资源：

Resource type:org.alljoyn.example，

Resource URI:/org/freedesktop/example，

Resouece interface:org.alljoyn.example.test。

(5)OCStack根据AllJoyn资源属性生成对应的DNS-SD查询消息。

(6)mDNS多播发送DNS-SD查询消息。

(7)AllJoyn服务端通过mDNS端口监听，收到DNS-SD查询消息，解析TXT记录，匹配对应的well-known name，对象路径和接口；

(8)在AllJoyn服务和OCF要发现的资源相互匹配后，AllJoyn服务端发送DNS-SD回复(单播响应)。

(9)OCF客户端收到DNS-SD回复，解析TXT记录，得到AllJoyn服务的资源属性，完成对AllJoyn服务资源的发现过程。

由上实例可知，本方案实现了OCF客户端对AllJoyn服务的发现，有效实现了OCF协议与AllJoyn协议互联互通。

以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。

Claims (3)

1.一种基于DNS-SD的OCF客户端对AllJoyn服务的发现方法，其特征在于，

所述OCF客户端通过OCF的资源发现接口发现AllJoyn服务资源，所述AllJoyn服务资源符合OCF标准资源定义规范；

所述OCF客户端的所述资源发现接口将所述AllJoyn服务资源生成AllJoyn标准的DNS-SD消息；

所述OCF客户端向AllJoyn服务端发送符合AllJoyn服务发现机制的所述DNS-SD消息；所述AllJoyn服务端收到所述DNS-SD消息后进行匹配，在所述AllJoyn服务和OCF要发现的资源相互匹配后，返回相应的DNS-SD响应消息给所述OCF客户端；

所述OCF客户端在接收到所述DNS-SD响应消息后，进行解析得到所述AllJoyn服务的资源属性。

2.根据权利要求1所述的OCF客户端对AllJoyn服务的发现方法，其特征在于，所述OCF客户端的所述资源发现接口将OCF的resource URI映射为所述DNS-SD消息中的TXT记录的“PATH＝{URI}”，对应于AllJoyn的对象路径；

将OCF的resourcetype映射为所述DNS-SD消息中TXT记录的“NAME＝{resourcetype}”，对应于AllJoyn的well-known name；

将OCF的resourceinteface映射为所述DNS-SD消息中TXT记录的“IF＝{resourceinterface}”，对应于AllJoyn的接口。

3.根据权利要求1所述的OCF客户端对AllJoyn服务的发现方法，其特征在于，以多播的方式发送所述DNS-SD消息。

Images