一种基于CoAP协议的动态超时算法制造技术

本发明专利技术公开了一种基于CoAP协议的动态超时算法，主要涉物联网通信技术领域，客户端发送CON消息之后，客户端可以跟踪为每个CON消息接收的ACK消息的数量，以及每个CON消息传输接收ACK消息的延迟，客户端可以动态地改变其ACK_TIMEOUT。假设客户端可以修改每个单独的客户端‑服务器链接或客户端‑服务器链接集的ACK_TIMEOUT，将ACK_TIMEOUT设置为方面保持消息交换短的最佳值或最小化重传比预期迟接收到的ACK消息的请求次数，使CoAP协议的重传机制的超时时间值更加合理且满足更多的链路，局域网内的端点通信及时性更强，且一定程度上减少了CON消息和ACK消息的冗余性，减小了网络拥塞。

【技术实现步骤摘要】
一种基于CoAP协议的动态超时算法
本专利技术涉及物联网通信
，具体的说，是一种基于CoAP协议的动态超时算法。
技术介绍
CoAP协议位于应用程序和传输协议之间。CoAP可以被认为是包括两个操作层。第一个CoAP层处理用户数据报协议(UDP)异步消息传递，第二个CoAP层处理承载request和response的CoAP方法，如GET，PUT，POST和DELETE，以及相关的响应代码。IETF定义了四种类型的COAP消息，可确认(CON)消息使用默认超时和响应的重传参数进行重传。确认(ACK)消息用于确认CON消息。例如，客户端会一直重发消息，直到接到服务器发过来的消息包含与原始消息匹配的消息ID的确认(ACK)消息为止。不可确认(NON)消息不需要可靠的传输。例如，传感器数据流中的每个单独测量都可以作为NON消息发送。这些消息不被确认，但是仍然包含用于重复检测的消息ID。当服务器不能处理NON消息时，可以使用reset(RST)消息。CoAP消息以简单的二进制格式编码，消息格式以固定大小的4字节报头开始，然后是可变长度的token值，长度可以在0到8字节之间。在token值后面是可选地类type-length-value(TLV)格式的零个或多个CoAP选项，再后面是占据数据报其余部分的有效数据区。消息头部中的字段如下，Version(Ver)是表示2位无符号整数的CoAP版本号，Type(T)是表示消息是可确认(0)、不可确认(1)、确认(2)，还是重置(3)，也占2位无符号整数。Token-Length(TKL)是4位无符号整数，表示可变长度令牌字段的长度，其中令牌字段的长度为0-8字节，保留令牌长度为9-15字节，但不能发送表示长度为9-15字节的令牌长度字段。如果收到了9-15字节的令牌长度消息，那么这个消息应该当做错误消息格式来处理过滤。Code是8位无符号整数，分为3-bit(最高有效位)和5-bit(最低有效位)，记录为c.dd，其中c是3位子字段的0到7位数，dd是5位子字段的00到31位数。其中3-bit字段可以指示请求(0)、成功响应(2)、客户端错误响应(4)或服务器错误响应(5)，此外作为特殊情况，代码0.00表示空消息。在请求的情况下，Code字段表示请求方法。在响应的情况下，Code字段表示响应代码。MessageID是按网络字节顺序排列的16位无符号整数，用于检测消息是否重复，并将Acknowledgement/Reset类型的消息和Confirmable/Non-confirmable类型的消息匹配起来。Header后面的字段是Token字段和选项，Token长度字段给出的是0到8个字节，用于关联请求和响应。Option后面可以是消息的结尾、另一个Option、或Payload标记(1111111)和Payload。CoAP定义了许多Option，这些Option可以包括在消息中。请求和响应都可以包括一个或多个Option的列表。消息中的每个Option实例指定了选项号、选项值的长度和选项值本身，选项值可以是空的、不透明的、Uint(非负整数)或字符串。当客户端希望一段时间内都可以拥有资源时，CoAP核心协议的请求-响应机制实际上是不能很好地支持。所以IETF工作组就在现在的核心协议上扩展客户端在服务器上拥有资源的机制，这里称之为观察机制。CoAP观察机制是一种订阅通知机制，客户端的一个请求将会触发服务器的多个响应。首先客户端通过向服务器发出扩展的GET请求来注册其对某资源的兴趣，然后服务器收到该请求后将客户端添加到某资源的观察者列表中，这样当某资源的状态发生改变后，将通过单播通知对该资源感兴趣的客户端。当客户端收到服务器的状态通知后，通过响应消息头中携带的Token将通知与原始请求相关联。客户端将会一直保留在观察者列表上，直到它要么：取消注册(取消其观察者注册)，要么拒绝来自服务器的通知；或者发送给服务器的可确认消息失败。同理，如果多个客户端多同一个服务器上的某个资源感兴趣，那么它们也可以在第一请求的时候就注册，服务器收到它们的请求后，会把所有对该资源感兴趣的客户端加入到一个列表中，这样当该资源的状态发生改变后，服务器会通知所有对该资源感兴趣的客户端。客户端发送请求到收到服务端的回复时间(RTT)大于了客户端设定的重传超时值。导致出现这样的现象的原因可能有，客户端和服务器之间的传播延迟；客户端和/或服务端的访问延迟；服务端准备计算响应的时间复杂度；服务器的延迟，例如由于睡眠周期造成的延迟等等。最后出现的结果就是，客户端收到的ACK时间远远晚于期望值。客户端需要可靠地发送请求，因此它使用可确认Message1。Message1具有0x7a33的MessageID，并且依赖于默认的传输参数，例如，ACK_TIMEOUT＝2秒，MAX_RETRANSMIT＝4。在重传超时1a到期之前没有接收到ACK。因此，客户端发送消息2，这是Message1的第一次重传。同样，在重传超时2a到期之前没有接收到ACK。因此，客户端发送Message3，这是Message1的第二次重传。由于往返时间较长，前两个传输中的每个都超时,结果客户机总共发送三次CON消息,在第三次传输之后，客户端才接收到MessageID＝0x7a33的第一个ACKMessage4。服务器发送此ACKMessage4以响应初始的新的可确认消息Message1请求。直到此时，客户端才知道刚才的请求成功，但是还是不知道接收的ACK是第一次发送的请求还是后面几次重传的请求之一。服务器从客户端接收到3个消息Message1-3，理论上，它可以使用MessageID来区分新Message1传输和重传Message2和Message3。此外，它还可以保证不会对同一CoAP请求进行多次接收操作。然而，实际上服务器并不知道其发出的ACK消息4-6是否已经到达客户端或已经丢失，因此它将继续发送ACK到每个接收到的Message。服务器将给Message2发送ACK5，给Message3发送ACK6，从而出现客户端随后将接收到多次(包括用于重传)ACK的结果。显然，重传的Message2和Message3实际上都是多余的，因为服务器已经收到了Message1，同样服务器针对客户端Message5和Message6发送的ACK5和ACK6也是多余的，因为客户端已经收到了Message1的ACK，也就是说本次请求回复已经成功了。客户端使用的是次优的重传超时值，超时值与客户端-服务器链路的实际性能不匹配，虽然CoAP标准协议支持动态调整该参数，但它不提供这样做的具体算法。CoAP依赖于UDP传输协议，提供自己的机制来确保可靠的消息传输。CON消息在重传之间使用默认超时和指数退避来重传，直到客户端从服务器接收到具有匹配消息ID的ACK。至于重传这个动作是否启动由超时时间和重传计数器控制。对于每个新的可确认消息，客户端选择一个初始超时，例如，选择默认ACK_TIMEOUT参数作为初始值。除此之外，客户端还将一个重传计数器初始化为0。当下面这种情况发生，如果超时被触发并且重传指示小于某个最大值，例如小于MAX_RETRAN本文档来自技高网...

【技术保护点】
1.一种基于CoAP协议的动态超时算法，其特征在于，所述方法包括以下步骤：步骤1：节点启动定时器并设置初值，并初始化消息的ACK计数和ACK延迟；步骤2：节点检查步骤1中的定时器是否过期；步骤3：若步骤2的检查结果为已经过期，则节点确定触发了定时器过期的消息，计算该消息的确认延迟统计数据，并确定CS_ACKCount和延迟然后清除消息的ACK计数和ACK延迟结果；若步骤2的检查结果为未过期，则转到步骤8；步骤4：节点检查CS_ACKCount是否大于TO_INCREASE_THRESHOLD；步骤5：若步骤4的检查结果为CS_ACKCount大于TO_INCREASE_THRESHOLD，则节点为节点‑节点链路增加了ACK_TIMEOUT值，确保ACK_TIMEOUT不超过最大值，然后此过程结束；步骤6：若步骤4的检查结果为CS_ACKCount不小于TO_DECREASE_THRESHOLD，如果不是则过程结束；步骤7：若步骤6中CS_ACKCount的值小于TO_DECREASE_THRESHOLD节点为节点‑节点链路减少了ACK_TIMEOUT值，节点确保ACK_TIMEOUT不小于最小值，然后此过程结束；步骤8：若步骤2的检查结果为未过期，未收到ACK则返回步骤2；步骤9：所述步骤8中若收到ACK，则节点确定收到ACK的所属消息，并且节点检测消息是否存在一个期望的ACK，若不存在则返回步骤2；步骤10：所述步骤9中若节点检测到存在一个期望的ACK，则节点增加此消息的维护的ACK计数，并更新此消息的ACK延迟总数，然后返回步骤2。...

【技术特征摘要】
1.一种基于CoAP协议的动态超时算法，其特征在于，所述方法包括以下步骤：步骤1：节点启动定时器并设置初值，并初始化消息的ACK计数和ACK延迟；步骤2：节点检查步骤1中的定时器是否过期；步骤3：若步骤2的检查结果为已经过期，则节点确定触发了定时器过期的消息，计算该消息的确认延迟统计数据，并确定CS_ACKCount和延迟然后清除消息的ACK计数和ACK延迟结果；若步骤2的检查结果为未过期，则转到步骤8；步骤4：节点检查CS_ACKCount是否大于TO_INCREASE_THRESHOLD；步骤5：若步骤4的检查结果为CS_ACKCount大于TO_INCREASE_THRESHOLD，则节点为节点-节点链路增加了ACK_TIMEOUT值，确保ACK_TIMEOUT不超过最大值，然后此过程结束；步骤6：若步骤4的检查结果为CS_ACKCount不小于TO_DECREASE_THRESHOLD，如果不是则过程结束；步骤7：若步骤6中CS_ACKCount的值小于TO_DECREASE_THRESHOLD节点为节点-节点链路减少了ACK_TIMEOUT值，节点确保ACK_TIMEOUT不小于最小值，然后此过程结束；步骤8：若步骤2的检查结果为未过期，未收到ACK则返回步骤2；步骤9：所述步骤8中若收到ACK，则节点确定收到ACK的所属消息，并且节点检测消息是否存在一个期望的ACK，若不存在则返回步骤2；步骤10：所述步骤9中若节点检测到存在一个期望的ACK，则节点增加此消息的维护的AC...

【专利技术属性】
技术研发人员：陈梁，何川，蒋启平，杨楚鹍，袁中庆，
申请(专利权)人：四川长虹电器股份有限公司，
类型：发明
国别省市：四川,51