Подтверждающий ответ CoAP

Мой сервер предоставляет набор измерений, но только те, которые еще не были прочитаны. Для этой цели я реализовал только один ресурс /new, который отбрасывает измерения, которые он только что отправил после запроса GET. Как заставить сервер ждать, пока запросчик подтвердит прием ответа?Подтверждающий ответ CoAP

Я знаю, что это не полностью уважает семантику CoAP, но это все равно будет полезно для меня. Я имею в виду, что сервер будет только отбрасывать показания, которые фактически были получены некоторым клиентом.

источник

2014-12-03 bbc

Вы, вероятно, решили его (в этом случае могли бы вы сказать, какой подход вы использовали? Я заинтересован). В любом случае, я думаю, вы должны использовать токен (https://tools.ietf.org/html/rfc7252#section-5.3.1). Это то, что я сделал бы:

1) Клиент отправляет запрос CON на сервер, содержащий токен сообщения.

2) Сервер отправляет пустой ACK с тем же токеном.

3) Сервер отправляет ответ CON, содержащий тот же токен и набор измерений.

4) Клиент отправляет пустой ACK с тем же токеном.

5) Теперь сервер может удалить ресурсы чтения.

источник

2015-02-23 23:27:47 Jiloc

Для меня не очевидно, что CoAP позволяет вам это делать. Токен предназначен для соответствия ответа с запросом, а не двух пар запроса-ответа. В моем случае я решил заставить сервер инициировать связь с клиентом с подтверждением запроса POST. – bbc

В отличие от идентификатора сообщения, который используется для уникальной идентификации сообщения и помогает серверу в обнаружении дубликатов, токен используется для корреляции сообщений, которые участвуют в одном наборе логически связанных транзакций, даже если идентификаторы сообщений различны. Здесь вы можете найти пример (рисунок 20) https://tools.ietf.org/html/rfc7252#page-108 – Jiloc

Я отредактировал свой ответ, чтобы использовать запрос NON клиентом для минимизации обмена сообщениями – Jiloc

сервер может удалить ресурс после его чтения.

вы также можете посмотреть на COAP-MQ с Draf для публикации/подписки на верхней части КоАП

источник

2014-12-04 12:52:08

Нет, читать недостаточно. Сервер должен убедиться, что клиент действительно получил ответ. Что касается CoAP-MQ, это кажется привлекательным решением, но я не думаю, что оно широко реализовано. Вообще говоря, паб/вспомогательная модель, такая как MQTT, может быть более подходящей для моего варианта использования из-за гарантий QoS, которые она может предоставить. – bbc

Хорошо, я допустил ошибку, когда сервер выделяет ресурсы и клиент их потребляет, после того, как он потребляется, клиент должен их удалить. –

Хорошо, вы можете это сделать, но оно включает в себя больше сообщений, которые могут стоить батареи для датчика. То, что я ищу, в основном является ответом, который является как ответным (отправленным по серверу), так и подтвержденным (сервер будет ждать, пока клиент отправит ack). Если это невозможно, ваше решение является приемлемой альтернативой. – bbc

Подтверждающий ответ CoAP

ответ

Смежные вопросы