我正在做一项关于CoAP扩展的工作，该扩展允许它使用发布/订阅代理模型，我目前正在分析如何在这里实现传输可靠性。CoAP中使用可确认和不可确认消息，以保证消息到达目的地。我的建议是，CoAP的扩展是否依赖于CoAP消息来保证传输的可靠性，因为我找不到任何关于这一点的内容。非常感谢。
在CoAP中，使用CONFIRM ABLE和NON-CONFIRM ABLe消息，以保证邮件到达目的地。
CON消息被重新发送，直到重新发送计数器到期或收到ACK/RST作为应答。这使得消息很可能到达目的地，但"保证"是另一回事。"切断线路"，任何技术都无法保证消息到达目的地。收到一个你可以信赖的ACK，消息到达了，但如果你没有收到，你就不知道。
重新传输会消耗带宽，发送"许多不同"的消息("不可靠"(与发送"一些"的信息("可靠"(的好处是特定于应用程序的。对于pubsub来说，特定于应用程序的决定也是正确的。我不确定为什么pubsub应该明确提到CON/NON行为。
仅举一例：这样的问题可以直接在IETF核心邮件列表中提出。在那里，你可以联系RFC的作者，并有机会获得他们的反馈。你需要在那里注册。
CoAP消息不可靠，甚至不能端到端传输——令牌、消息ID甚至观察号等内容可能会在存在代理的情况下发生变化。
特别是，无论在哪里使用观察(包括发布/发布(，都不能保证观察者收到特定的陈述；所保证的(并通过作为观察的一部分定期发送的CON消息来确保(是，从长远来看，客户端最终会得到与服务器相同的表示(也称为"最终一致性"(。这是一个重要的功能，因为它甚至可以在拥塞的网络上运行。
为了举例说明，服务器可以首先发送值"14.7"，然后在NON中发送"14.8"，代理可以将"14.8(转发给客户端。然后，服务器可能会在CON中发送"14.9"，代理会确认这一点，但可能代理很忙，会延迟向客户端发送通知。接下来，服务器发送"15.0"，代理立即转发。您可以看到，客户从未收到"14.9"，尽管它是CON，但它确实得到了后来的值。
诚然，并不是每个部署都使用代理，但REST架构设计的一部分是，其中的一切都需要正常工作(如果有的话(。