我正在做有关CoAP扩展的工作，使其可以使用发布/订阅代理模型，而我目前正在分析Transmision Reliabilty的完成方式。在CoAP中，使用CONFIRMABLE和NON-CONFIRMABLE消息来保证消息到达目的地。我的建议是，如果CoAP的这种扩展依赖于此CoAP消息来保证传输的可靠性，因为我找不到任何有关此的信息。谢谢。
在CoAP中使用了CONFIRMABLE和NON-CONFIRMABLE消息，以确保消息到达目的地。
CON消息被重新发送，直到重新发送计数器到期或收到ACK / RST作为应答为止。这使得消息很可能到达目的地，但是“保证”是另外一回事。 “切断线路”并且没有任何技术可以保证消息到达目的地。您可以依靠收到一个ACK来确认消息已到达，但是如果您未收到它，则您将不知道它。
重传会消耗带宽，并且发送“许多不同”消息（“不可靠”）与“某些”消息（“可靠”）的好处是特定于应用程序的。该应用程序特定的决定也适用于pubsub。我不确定，为什么pubsub应该因此明确提及CON / NON行为。
仅提：这些问题可以直接在IETF Core Mailinglist中提出。您可以在那里与RFC的作者联系，并且有机会获得他们的反馈。您将需要在那里注册。
CoAP 消息不可靠，甚至无法端到端传输-令牌，消息ID甚至观察号之类的内容在存在代理的情况下可能会发生变化。
特别是，无论在何处使用观察（包括发布/订阅），都不能保证特定的表示会到达观察者；保证（并由作为观察结果一部分定期发送的CON消息来保证）的是，从长远来看，客户端最终将具有与服务器相同的表示形式（也称为“最终一致性”）。这是一项重要功能，因为它甚至可以在拥塞的网络上运行。为了举例说明，服务器可以首先发送值“ 14.7”，然后在NON中发送值“ 14.8”，并且代理可以将“ 14.8”转发给客户端。然后，服务器可能会在CON中接下来发送“ 14.9”，代理会对此进行确认-但是代理可能很忙，并延迟了向客户端发送通知的时间。接下来，服务器发送“ 15.0”，并且代理立即转发它。您会看到，即使是CON，客户也从未收到过“ 14.9”，但确实得到了更高的价值。
当然，并不是每个部署都使用代理，但这是REST体系结构设计的一部分，其中的所有内容都必须工作得很好，如果有的话。