Подтверждаемый ответ CoAP

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

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

Я отредактировал свой ответ, чтобы использовать запрос клиента NON, чтобы свести к минимуму обмен сообщениями - person Jiloc; 24.02.2015

На самом деле токен предназначен для связывания ответа с запросом, а не для нескольких таких пар. RFC даже предполагает, что это могло быть названо идентификатором запроса и что клиент не должен повторно использовать токены с данной конечной точкой сервера. Конечно, ID сообщения разные, они связывают сообщение CON с соответствующим ACK. Кроме того, в вашем 2), я думаю, вы имели в виду ответ, а не запрос. - person bbc; 24.02.2015

Ваше предложение действительно, потому что оно решает проблему, заставляя сервер отправлять ответ отдельно и, таким образом, иметь возможность сделать его подтверждаемым. Я бы хотел, чтобы это можно было сделать с двумя сообщениями CON и двумя ACK, причем первое было совмещено, но это не представляется возможным. - person bbc; 24.02.2015

Это распространенное заблуждение. RFC не ясен, в нем говорится, что клиент ДОЛЖЕН генерировать токены таким образом, чтобы токены, используемые в настоящее время для данной пары конечных точек источника / назначения, были уникальными. Это означает, что в любой момент времени КЛИЕНТ не может сгенерировать новый ЗАПРОС с тем же токеном, или он может быть запутан. Он был введен для управления такими вещами, как отдельные ответы (в данном случае) tools.ietf. org / html / rfc7252 # section-5.2.2 и параметр наблюдения. Фактически, как вы можете видеть в примере в RFC со стр. 107, ЗАПРОСЫ, отправленные СЕРВЕРОМ, содержат тот же ТОКЕН, полученный от клиента. - person Jiloc; 25.02.2015

Я отредактировал свой ответ, чтобы использовать 2 запроса CON, как вы просили. Как видно на рисунке 20, tools.ietf.org/html/rfc7252#page-108 запросы, отправленные сервером, содержат тот же ТОКЕН, отправленный клиентом. - person Jiloc; 25.02.2015

Нет, я не думаю, что пример со страницы 107 подтверждает вашу позицию, потому что второе клиентское сообщение - это просто повторная передача того же запроса. Даже идентификатор сообщения идентичен. Кроме того, как я уже сказал, ваш 3) не является запросом, это ответ сервера на запрос клиента и, следовательно, содержит тот же токен. Другие ваши объяснения мне верны. - person bbc; 26.02.2015

Я соответствующим образом отредактировал ваш ответ и пометил его как правильный, так как он лучший из имеющихся. - person bbc; 26.02.2015

Да, моя ошибка, страница 107 (рисунок 19) - это просто повторная передача, я хотел, чтобы вы посмотрели страницу 108 (рисунок 20 - прекрасный пример) и следующую (рисунки 21 и 23). И извините за недоразумение с запросами и ответами на моем 3-м шаге. Я обычно называю запросы сообщениями CON и NON и отвечаю сообщениями ACK и RST, но это личная концепция. - person Jiloc; 27.02.2015

Рисунки 20, 21 и 23 подтверждают, что токен позволяет клиенту узнать запрос, от которого исходит ответ, и что он очень полезен для случаев использования, упомянутых в RFC. Все, что я сказал, кажется правильным. Чтобы прояснить словарь, используемый RFC: он определяет, что могут быть запросы CON / NON, а также ответы CON / NON. Ответ должен содержать тот же токен, что и соответствующий запрос. Сообщение CON включает в себя сообщение ACK, содержащее тот же идентификатор сообщения, что и сообщение CON, которое оно подтверждает, будь то запрос или ответ. - person bbc; 28.02.2015

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

Хорошо, я совершил ошибку, сервер добавляет ресурсы, и клиент их потребляет, после того, как они потребляются, клиент должен удалить их. - person Julien Vermillard; 05.12.2014

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

Я думаю, что то, что вы ищете, является надежным пабом / подпиской, например MQTT - person Julien Vermillard; 05.12.2014