CoAP 可确认的反应答案

【问题标题】：CoAP confirmable responseCoAP 可确认的反应
【发布时间】：2014-12-03 15:15:40
【问题描述】：

我的服务器公开了一组测量值，但只公开了尚未读取的那些。为此，我只实现了一个资源/new，它丢弃了它在GET 请求之后刚刚发送的测量值。如何让服务器等待请求者确认收到响应？

我知道这并不完全尊重 CoAP 语义，但它仍然对我有用。我的意思是服务器只会丢弃某些客户端实际收到的读数。

【问题讨论】：

标签： coap

【解决方案1】：

您可能解决了它（在这种情况下，您能说出您使用了哪种方法吗？我很感兴趣）。无论如何，我认为您应该使用令牌 (https://www.rfc-editor.org/rfc/rfc7252#section-5.3.1)。这就是我会做的：

【讨论】：

CoAP 允许您这样做对我来说并不明显。令牌旨在将响应与请求匹配，而不是两对请求-响应。就我而言，我选择让服务器使用可确认的 POST 请求来启动与客户端的通信。
与消息ID不同，消息ID用于唯一标识一条消息并帮助服务器进行重复检测，Token用于关联参与单个逻辑相关事务集合的消息，即使消息标识符不同。您可以在此处找到示例（图 20）tools.ietf.org/html/rfc7252#page-108
我编辑了答案以使用客户端的 NON 请求来最大程度地减少消息交换
一个令牌实际上是为了将响应与请求相关联，而不是几个这样的对。 RFC 甚至建议它可以被命名为“请求 ID”，并且客户端不应该重复使用给定服务器端点的令牌。当然消息 ID 是不同的，它们将一个 CON 消息与其对应的 ACK 相关联。此外，在您的 2) 中，我认为您的意思是响应，而不是请求。
您的建议是有效的，因为它通过强制服务器单独发送响应来解决问题，从而能够使其可确认。我希望它可以通过两个 CON 消息和两个 ACK 来完成，第一个被捎带，但这似乎是不可能的。

【解决方案2】：

一旦资源被读取，服务器就可以删除它。

您还可以查看 CoAP-MQ 草案，用于在 CoAP 之上发布/订阅

【讨论】：

不，被阅读是不够的。服务器必须确保客户端确实收到了响应。关于 CoAP-MQ，这似乎是一个有吸引力的解决方案，但我不认为它被广泛实施。一般来说，像 MQTT 这样的发布/订阅模型可能更适合我的用例，因为它可以提供 QoS 保证。
好吧，我犯了一个错误，服务器 plublish 资源和客户端消耗它们，一旦消耗，客户端必须删除它们。
好的，你可以这样做，但它涉及更多的消息，这可能会消耗传感器的电池。我正在寻找的基本上是一个响应，它既是捎带的（沿着服务器的确认发送）又是可确认的（服务器将等待客户端发送确认）。如果这是不可能的，那么您的解决方案是一个可以接受的替代方案。
我认为您正在寻找的是可靠的发布/订阅，例如 MQTT