CoAP发布/订阅传输可靠性

Question

我正在做有关CoAP扩展的工作，该扩展使其可以使用发布/订阅代理模型，并且我目前正在分析Transmision Reliabilty的完成方式。在CoAP中，使用CONFIRMABLE和NON-CONFIRMABLE消息来保证消息到达目的地。我的建议是，如果CoAP的这种扩展依赖于此CoAP消息来保证传输的可靠性，因为我找不到任何有关此的信息。谢谢。

Answer 1

在CoAP中使用CONFIRMABLE和NON-CONFIRMABLE消息来 确保邮件到达目的地。

CON消息将被重发，直到重发计数器到期或接收到ACK / RST作为应答为止。这使得消息很可能到达了目的地，但是“保证”是另外一回事。 “切断线路”并且没有任何技术可以保证消息到达目的地。接收到您可以依靠的ACK消息即已到达，但是如果您未收到它，则您将不知道它。

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

只需提及： 这些问题可以直接在IETF Core Mailinglist中提出。您可以在那里与RFC的作者联系，并且有机会获得他们的反馈。您将需要在那里注册。

Answer 2

CoAP 消息不可靠，甚至无法端到端传输-如果存在代理，令牌，消息ID甚至观察号之类的内容可能会发生变化。

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

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

当然，并不是每个部署都使用代理，但是这是REST体系结构设计的一部分，其中的所有内容都必须工作正常（如果有的话）。