Як правило, вам потрібно буде вибрати протокол із чіткими гарантіями щодо того, чи отримає клієнт будь-які пакети / повідомлення, в якому порядку та чи дозволяється дублювання.
Для мережі пристроїв IoT, що надсилають один одному повідомлення малого та середнього розміру , використання MQTT з якістю обслуговування 2 , здавалося б, добре відповідає вашому випадку використання. Як зазначено у посиланні HiveMQ:
Найвищий рівень QoS - 2, це гарантує, що кожне повідомлення буде отримано лише один раз контрагентом. Це найбезпечніший, а також найповільніший рівень обслуговування. Гарантія забезпечується двома потоками туди і назад між відправником і одержувачем.
Зауважте, що QoS 2 зберігає порядок повідомлень і, як зазначено, запобігає дублюванню повідомлень.
У використанні MQTT QoS 2 є суттєві витрати в порівнянні зі стандартним QoS 0 (який схожий на повідомлення про пожежу та забуття; якщо воно не потрапляє до брокера, повідомлення не буде обурене і воно назавжди зникне ) - QoS 2 вимагає 4 повідомлень ( PUBLISHвід відправника, PUBRECвід брокера, PUBRELвід клієнта, PUBCOMPвід брокера), тому обробка, як правило, займе більше часу, забирає більше ресурсів (отже, довші радіопередачі та більше енергоспоживання на будь-яких обмежених кінцевих точках).
Повідомлення MQTT QoS 2 просто повторно відправиться від відправника до тих пір, поки він не отримає підтвердження від брокера, тому зрештою ваше повідомлення повинно пройти, навіть якщо ваше з'єднання недосконале.
Чи підходить тематичний протокол публікації та підписки для Вашого випадку використання, Вам належить визначити; стаття у Вікіпедії може допомогти вам отримати ідею.