Кілька роздумів про мій досвід роботи з TCP, UDP та MQTT, а також деякі додаткові ресурси для перегляду.
За допомогою UDP я зіткнувся з проблемою тихої несправності, в якій додаток на одному мережевому вузлі, клієнт, бачить лише деякі повідомлення UDP, які були надіслані. Занадто багато причин, через які мережевий трафік може піти не так. Проблема з UDP полягає в тому, що пакети можуть бути відкинуті майже завжди, коли будь-який із вузлів мережевого шляху між виробником пакетів та споживачем пакетів вимагає. Дивіться тему Вікіпедії Втрата пакетів .
Питання полягає в тому, яка ваша втрата за будь-якого поточного контексту мережі. Отже, якщо це спілкування в межах локальної мережі або підмережі, ваш рівень втрат може бути низьким. У мережі WAN або через Інтернет ваш рівень втрат може бути досить високим. Пакети UDP з декількох причин відкидаються і маршрутизуються, проте мережеві умови дозволяють зменшити кількість переходів. Відправлення пакетів у велику порожнечу без відповідальності залишає відкритим можливість безшумних збоїв.
Це здається, що у вашому випадку достатньо просто просту дію з повторною передачею після тайм-ауту, не отримуючи жодного.
Я робив XML-повідомлення через підтримуване TCP-з'єднання, і це чудово працювало. У мене був шар, який доставляв повне повідомлення кожне в буфері до рівня програми для обробки. Я використовував XML для упаковки повідомлення із початковим тегом XML для початку повідомлення та тегом закінчення XML, щоб знати, коли було отримано все повідомлення.
TCP має кілька функцій, таких як послідовний порядок пакетів, відсутність повторів, а те, що є підключеним транспортним механізмом, означає, що ви знаєте, зникає чи ні інший кінець, хоча це може зайняти деякий час. Підключення та відключення може спричинити затримки, але не обтяжливі в звичайних умовах, хоча мережеві умови можуть призвести до сповільнення пропускної здатності TCP.
MQTT - це протокол, який транспортується мережевим транспортним рівнем, як правило, TCP. MQTT використовує модель публікації / підписки, щоб не зберігати повідомлення. Отже, коли видавець публікує повідомлення, якщо підписник не підключений у той момент, коли він дійсно підключається, він не побачить повідомлення. MQTT - це майже в реальному часі, я вважаю, що це те, що є частиною телеметрії в абревіатурі. Мені подобається MQTT для невеликих повідомлень і роблю кілька експериментів з корисним навантаженням JSON через MQTT за допомогою Mosquitto. Дивіться цю статтю Надійна доставка повідомлень за допомогою Mosquitto (MQTT) з оглядом MQTT та якості обслуговування. І дивіться цю коротку статтю із посиланнями на ресурси, включаючи зразок програми IoT - MQTT Publish і Subscriber C Code .
Мої експерименти з MQTT, використовуючи текст JSON та базу даних SQLite3 у підписника для зберігання повідомлень, знаходиться за адресою https://github.com/RichardChambers/raspberrypi/tree/master/mqtt, хоча джерело знаходиться в C і досить безладно.
Ось 13-хвилинне відео № 144 Інтернет-протоколів: CoAP проти MQTT, мережевий снайпер та підготовка до злому IKEA Tradfri . Це цікава стаття про CoAP, протокол обмеженого застосування: CoAP - це «сучасний» протокол IoT . Є такий підсумок CoAP:
Ранні користувачі погоджуються, що протокол обмеженої програми працює надзвичайно добре для обмежених мереж та пристроїв. Щось не так відоме: "У дуже перевантаженій бездротовій мережі - Wi-Fi або стільниковій - CoAP може продовжувати працювати там, коли протокол на основі протоколу управління передачею (TCP) на зразок MQTT навіть не може встигнути завершити рукостискання" - сказав Вермільярд.
Це тому, що на відміну від більшості інших протоколів IoT, CoAP побудований на UDP. Іншими словами, це означає відсутність рукостискань з протоколом або виправлення помилок, як це трапляється з TCP. "CoAP може бути не таким надійним, як HTTP або гарантувати доставку повідомлень, таких як MQTT, але це надзвичайно швидко", - зазначив Матьє. "Якщо у вас все в порядку, коли деякі повідомлення не надходять, ви можете надсилати ще багато повідомлень у той же часовий період."
Є кілька інших, таких як AMQP, STOMP і CBOR, на які ви також можете поглянути. Див. Веб-сайт стандарту CBOR , а також цю тезу, впровадження та оцінку протоколу CBOR . Дивіться цю статтю: Вибір протоколу обміну повідомленнями: AMQP, MQTT або STOMP, який порівнює та протиставляє AMQP, MQTT і STOMP і закінчується приміткою про брокера RabitMQ:
Сподіваємось, це може допомогти багатьом почати орієнтуватися на протокол супу для кожного із ваших випадків використання. Оскільки компаніям прийнято мати багато додатків з різними потребами, безумовно, можливо, вам можуть знадобитися всі три брокери в різних додатках. Ось тут і надійний мультипротокольний поліглот-брокер на зразок RabbitMQ, оскільки він може надсилати STOMP, MQTT або AMQP і виводити один з інших. Вам не потрібно бути заблокованим одним із цих протоколів - усі три підтримуються брокером RabbitMQ, що робить його ідеальним вибором для взаємодії між програмами. Архітектура плагінів також дозволяє RabbitMQ розвиватися для підтримки додаткових або оновлених версій цих протоколів у майбутньому.
Цей пакет слайдів із 60 слайдів дає порівняння та контраст між чотирма різними протоколами IoT, розглядаючи потреби двох різних IoT-груп, споживчих та промислових, які мають різні потреби в надійності та надійності. Що таке стандарт правильних повідомлень для IoT? .
Acking не є необхідним. Я думаю, що працювати над надійністю поверх UDP не має занадто великого сенсу, саме для цього і є TCP.