CoAP pub/sub 传输可靠性

Posted 2023-03-07

【中文标题】CoAP pub/sub 传输可靠性

【英文标题】：CoAP pub/sub transmision reliability

【发布时间】：2020-05-09 10:56:02

【问题描述】：

我正在做一个关于 CoAP 扩展的工作，它允许它使用发布/订阅代理模型，我目前正在分析如何在这里完成传输可靠性。在 CoAP 中使用 CONFIRMABLE 和 NON-CONFIRMABLE 消息，以保证消息到达目的地。我的建议是，如果 CoAP 的这个扩展依赖于这个 CoAP 消息来保证传输可靠性，因为我找不到任何关于这个的东西。谢谢你。

【问题讨论】：

澄清问题：您是否在问 IETF 规范草案“CoAP 的发布-订阅代理”是否依赖可确认的消息来要求消息可靠性？ core-wg.github.io/coap-pubsub/draft-ietf-core-pubsub.html

@jonathanberi 正是我要问的

【参考方案1】：

在 CoAP 中使用 CONFIRMABLE 和 NON-CONFIRMABLE 消息，以 保证消息到达目的地。

CON 消息被重传，直到重传计数器到期或收到 ACK/RST 作为应答。这使得消息很可能到达目的地，但“保证”是另一回事。 “切断电线”，没有任何技术可以保证消息到达目的地。收到一个 ACK​​，你可以相信消息已经到达，但如果你没有收到，你就不知道它。

重传会消耗带宽，发送“许多不同”消息（“不可靠”）与“某些”消息（“可靠”）的好处是特定于应用程序的。 该应用程序特定的决定也适用于 pubsub。我不确定，为什么 pubsub 应该因此明确提及 CON/NON 行为。

顺便提一下： 此类问题可直接在IETF Core Mailinglist 中提问。在那里，您可以联系到 RFC 的作者，并且您有机会获得他们的反馈。您需要在那里注册。

【讨论】：

非常感谢您的回答，但也许我在问题中表达得不好。 CoAP 定义了一个扩展 here，允许该协议使用 pub / sub 代理架构，我想知道的是，尽管此实现使用新消息作为代理公开的新 REST API 的一部分，但我想知道的是使用 CONFIRMABLE 消息和 coAP 的其他功能来确保消息可靠性，以确保消息 ID 和令牌等可靠性。但我一定会检查你的来源，谢谢。

RFC-draft 包含 pub/sub 操作到 CoAP 原语的映射，例如发现 => 获取 +ps/+topic?q*。尽管该映射使用标准 CoAP 请求（例如 GET、PUT 或 POST），但仍照常使用 CON 和 NON。同样适用于 message-id 或 token，这里没有新的介绍。所以 pubsub 定义了，如何使用 CoAP，它不适配 CoAP。

【参考方案2】：

CoAP 消息 不可靠，甚至不能端到端传输 - 令牌、消息 ID 甚至观察编号等内容可能会在代理存在时发生变化。

特别是，无论何时使用观察（包括发布/订阅），都不能保证特定的表示到达观察者； 保证（并通过作为观察的一部分定期发送的 CON 消息来保证）是，从长远来看，客户端最终会得到与服务器相同的表示（也称为“最终一致性”） ”）。这是一项重要功能，因为它甚至可以在拥塞的网络上运行。

为了举例说明，服务器可能首先发送一个值“14.7”，然后在 NON 中发送“14.8”，代理可以将“14.8”转发给客户端。然后，服务器可能会在 CON 中下一个发送“14.9”，代理会对此进行确认 - 但代理可能很忙，并且会稍微延迟向客户端发送通知。接下来，服务器发送“15.0”，代理立即转发。您会看到客户端从未收到“14.9”，即使它是 CON，但它确实获得了较晚的值。

当然，并非每个部署都使用代理，但这是 REST 架构设计的一部分，其中的所有内容都需要能够正常工作（如果有的话）。