一种基于组播技术的CoAP协议通知优化方法与流程

本发明涉及物联网通信技术领域，具体的说，是一种基于组播技术的coap协议通知优化方法。

背景技术

现有使用coap协议的客户端-服务器模型采用一种订阅-通知的通信机制，大概可以表述为，客户端可以订阅服务器上自己感兴趣的资源，服务器将保存对该资源感兴趣的客户端信息，然后在当某个时刻，该资源的状态发生变化后，通过单播的方式主动地发送消息通知给通知感兴趣的客户端。如果在单播通知的过程中出现了超时重传等现象，那么服务器发送单播的次数将大大高于实际预期的次数，这样很可能会增加网络拥塞，且也降低了服务器的性能，同时也浪费了流量，因为在超时重传的时候，客户端可能已经收到前一次的请求的回复ack了。显然，这种逐个通知的方式，效率较为低下。

技术实现要素：

本发明的目的在于提供一种基于组播技术的coap协议通知优化方法，用于解决现有技术中单播方式容易增加网络拥塞，降低服务器性能的问题。

本发明通过下述技术方案解决上述问题：

一种基于组播技术的coap协议通知优化方法，包括：

步骤s100：客户端向服务器发送注册感兴趣的资源url的请求；

步骤s200：服务器收到请求后将客户端添加到所述资源url的观察者列表中；

步骤s300：服务器创建资源url的多播组；

步骤s400：服务器监测到所述资源url的状态发生改变后，通过广播方式通知多播组成员。

服务器收到注册请求后，会把客户端消息中带的组播信息加入到自身维护的多播组中；服务器收到取消注册请求后，会把客户端消息中带的组播信息从自身维护的多播组中移除。通过监控客户端对资源的请求，服务器可以确定资源何时应该多播或单播通知客户端，并且可以通过注册请求和取消注册请求管理多播组成员。

对于资源的状态可能频繁发生改变的服务器来说，服务器可以跟踪有多少个客户端正在观察每个可用的资源，并管理一个组来优化通知，它可以根据对可用资源的观察数量来创建、更新和删除组，可以确定通过创建多播组来更有效地管理和更新动资源的动态信息，而不是仅仅通过单播来通知已经订阅该资源的客户端。

进一步地，所述步骤s300中服务器创建资源url的多播组的流程包括：

步骤a1：服务器监测客户端向资源url发出了观察注册，则进入步骤a2；

步骤a2：节点检查是否已经存在用于资源url的多播组，如果不存在，进入步骤a3，否则，进入步骤a4；

在步骤a3中，节点创建多播组，其成员是对资源url进行主动观察的客户端，节点为多播组分配一个组播地址，且为触发组播通知资源url分配组播地址，然后，服务器通知多播组成员；

在步骤a4中，资源url的观察注册的客户端数量超过设定阈值，则创建一个新的多播组，否则，节点将客户端作为新成员添加到现有的多播组中，并通知其它的多播组成员。

进一步地，所述步骤s100具体包括：

步骤s110：管理实体向服务器发送有资格创建多播组的资源列表；

步骤s120：客户端向服务器发送注册感兴趣的资源url的请求；

步骤s130：服务器向客户端发送状态通知，所述状态通知消息头中携带的token将状态通知与请求关联。

本发明与现有技术相比，具有以下优点及有益效果：

(1)本发明通过在服务器使用组播技术通知客户端的请求或者感兴趣的资源后，可以大大的提高客户端-服务器的通信能力，降低网络拥塞的风险。

(2)可以通过注册请求和取消注册请求管理多播组成员，通过监控对资源的请求，服务器可以确定资源何时应该多播或单播通知客户端。

附图说明

图1为本发明的客户端与服务器的资源请求示意图；

图2为服务器为客户端建立多播组的流程图；

图3为服务器向客户端发送多播信息的流程图。

具体实施方式

下面结合实施例对本发明作进一步地详细说明，但本发明的实施方式不限于此。

实施例1：

结合附图1所示，一种基于组播技术的coap协议通知优化方法，基于coap协议的客户端注册了一个对服务器中资源为“/温度”感兴趣的请求，客户端收到服务器的状态通知后，通过响应消息头中携带的token将通知与原始请求相关联；同理，如果多个客户端都对服务器上的某个资源感兴趣，那么它们也可以在第一请求的时候就注册，服务器收到它们的请求后，会把所有对该资源感兴趣的客户端加入到一个资源列表中，创建组播组，这样当该资源的状态发生改变后，服务器会采用组播的方式通知组播组成员中的客户端。

结合图2所示，管理实体(me)通过message1向服务器发送有资格创建多播组的资源列表和多播组创建相关的参数，例如，可以在多播组中写入它可以最小或者最大监听多少个多播组的数量，me还可以提供创建多播阀值，该阈值是观察者列表中对某个资源的客户端数量。客户端使用post方法发送到服务器路径“observe-group”来创建新的观察组，其中服务器返回的内容包含合格资源的列表和观察组的配置参数(比如索引)。

例如，message1包含“post/observe-group”的请求，返回的内容包括用于observe-group的配置参数和监视用于潜在组观察的资源列表，例如：

“observe_multicast_create_threshold”:“2”，

“observe_multicast_delete_threshold”:“1”

“url-1”，“url-2”

此时服务器可能以下列消息响应，它包含：

result：2.01created

location-path：/observe_group/12

可选地，为触发多播组创建和/或组删除设置的阈值可以是url特定的。也就是说，每个有效的url可以有自己的多播组创建和删除值。在步骤2中，服务器开始监视包括有效资源的观察组中的资源，在步骤3中，客户端1发出请求消息3以观察合格资源url-1。在请求消息3中，客户端1指定它愿意接收组通知作为选项，此时它可以被服务器通过观察选项发出信号来告知某资源状态改变的具体信息。例如，message3包含下列信息：

observe-goupnotification＝yes

observe-goupnotification这个选项允许客户端告诉服务器它是否愿意并且能够接收组通知，设定为yes，表明它愿意接受组通知。

为了响应message3，服务器将client1添加到针对资源url-1的观察者列表中，并向client1发送响应4。由于资源url-1是有效的资源，如message1中配置的，服务器检查观察者的数量现在是否足以触发多播组的自主创建，配置的阈值是2，目前client1是唯一的观察者，所以小于配置的阈值，服务器不设置任何多播组。在时刻5，服务器检测到资源url-1的状态发生改变，然后向client1发送单播响应通知message5a。接下来，client2发出request6以观察有效的资源url-1。request6指定client2不愿意接受组观察通知作为选项。例如，request6可以包括：

observe-goupnotification＝no

服务器将client2添加到资源url-1的观察者列表中，并用message7响应来自client2的观察请求。消息7包含request6所请求的资源的具体信息。由于资源url-1是一个有效的资源，服务器可以再次检查观察者的数量是否足以触发多播组的自主创建，配置的阈值是两个，并且当前client1是唯一愿意接受多播的观察者。由于愿意接受组中成员资格的观察员数量少于配置的阈值，所以不设置任何组。接下来，client3发出一个request8以观察符合条件的资源url-1。在request8中，客户端指定它愿意接受组观察通知作为选项。例如，请求request8可以包括：

observe-goupnotification＝yes

服务器将client3添加到资源观察者列表url-1，并用message9响应client3的观察请求，message9包含该请求的具体资源信息。在步骤2a中，由于资源url-1是有效的资源，所以服务器可以再次检查观察者的数量现在是否足以触发组播组的自主创建，其配置的阈值是2，现在client1和client3是愿意接受多播的观察者。由于愿意接受成员资格的观察者数量已经足够，所以创建了一个组，该组有两个成员，client1和client3。服务器可以在message10中通知me已经创建了观察组。message10可以指定资源，在本例中是url-1。me可以使用该信息来维护关于对该资源发送组通知的统计数据，并且可能根据需要更改配置参数。

结合图3所示，服务器接下来使用成员配置restful接口在client1中创建组成员关系。在message11中，服务器提供多播地址，在message12中，client1确认组创建。

在步骤12a中，client1配置组成员关系，并将分配的多播地址与图2中的初始get请求message3中使用的token相关联。类似地，在message13中，服务器在client3中创建组成员关系，client3在message14中确认该组成员关系，并在步骤14a中进行处理。在时刻15，资源url-1的状态发生了变化，因此服务器向观察组发送多播通知15a，message15a由client1和client3相应地接收，当然服务器也会分别向没有在观察组列表中的任何客户端发送单播通知。

尽管这里参照本发明的解释性实施例对本发明进行了描述，上述实施例仅为本发明较佳的实施方式，本发明的实施方式并不受上述实施例的限制，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式将落在本申请公开的原则范围和精神之内。