Який тип повідомлень можна використовувати для протоколів IoT, орієнтованих на стільникову мережу?

Це мені прийшло до відома нещодавно, коли я знайшов дивовижне відео на Youtube:

Міхель Е. Андерсон: Порівнюючи методи обміну повідомленнями для IoT, OpenIoTSummit, Linux Foundation .

Слайди для його розмови доступні тут

На слайді 26 та 41 хвилини відео він обговорює, як (дозвольте перефразувати):

Мобільні носії вважають за краще, щоб їхні користувачі IoT використовували HTML , XML або JSON повідомлення, оскільки вони споживають більше даних. Більше даних означає, що вони можуть стягувати з споживачів більше грошей за послугу.

Я розумію, що багато власних протоколів саме. SigFox , Wireless HART або Z Wave мають більш низькі швидкості передачі даних, а надсилання об'ємних даних через такі оператори може бути дорогою справою.

Питання

• Чи існують інші формати обміну повідомленнями з легкої ваги , які використовуються для використання у власних протоколах, що робить їх економічно вигідними рішеннями для нинішніх та майбутніх споживачів IoT? (Знято в темряві: десь лежить якийсь формат під назвою легкий XML або HTML або JSON ?)

• Можливо, щось на зразок CBOR є або, можливо, використовується?

Ви питаєте про протокол чи формат повідомлення ? Ми часто неправильно використовуємо термін протокол, коли маємо на увазі формат даних. Я роблю це сам, часто тому, що відмінність не всім зрозуміла.

Протоколи обміну повідомленнями, які використовуються в IoT, як правило, досить компактні, принаймні більше, ніж http, і пропонують значні функції, важливі для обміну повідомленнями (сеанси, контроль потоку, надійність тощо). Формат повідомлення - це дані у повідомленні, яке надсилаються. Я припускаю, що про це ви просите.

Найбільш компактний формат повідомлень - це ретельно продуманий ручний двійковий формат. Він часто використовується в сценаріях з низькою пропускною здатністю, коли потрібно надіслати кілька байтів, і точно знати, як виглядають ці байти. Для більш великих повідомлень недоліки є істотними, і взагалі їх слід уникати будь-якою ціною.

Я пройшов детальну оцінку багатьох варіантів серіалізації даних. Я очікував, що протобуф, пакет повідомлень буде досить компактним, яким вони були. Однак моєю другою проблемою було пошук бібліотек, які підтримувались та були доступні на кількох різних платформах, включаючи C на пристрої.

Формат, який я влаштував, на диво, був стиснутим Gzip JSON. Це легко здійснити та зрозуміти, працює скрізь, і за даними, якими я користувався, було приблизно однаковим чи меншим, ніж інші методи.

Також майте на увазі, що якщо у вас є захищений канал, наприклад TLS, ви все одно будете споживати шматок даних (> 6 КБ) в рукостисканні TLS.

Кілька років тому я очікував, що такий формат, як буфери протоколів, буде домінувати, але насправді цього мало. Можливо, через простоту, при якій json можна виписати та проаналізувати (і стиснути). Мені подобається зовнішній вигляд Flatbuffers , але перевага більше в швидкості розбору, ніж у компактності.

Оскільки ви перебуваєте на етапі розслідування, я пропоную вам написати трохи коду на кожному, використовуючи дані, характерні для вашої ситуації, та провести деякі порівняння. Наявність важких даних під час запуску допомагає підтвердити свій вибір.

Великою перевагою формату розмітки є те, що ви зберігаєте гнучкість у виборі даних, які ви передаєте. Це надзвичайно важливо для екосистеми, що розвивається, де ви очікуєте, що послуга розвиватиметься протягом кількох років розвитку.

Хоча щільно закодована двійкова структура даних буде ефективною для передачі, вам потрібно визначитись наперед, як мінімум, як виглядатиме структура. Коли пізніше ви зрозумієте, що навіть одне поле потребує розширення, ви застрягли. Навіть розгортання оновлення до протоколу важко, оскільки ви не можете застаріти старим кодуванням, поки не буде оновлена ​​кожна кінцева точка.

Це говорить про те, що оптимальним підходом є змішування мінімалістичних пакетів та кодування на основі розмітки (використання останнього як резервний). Значення цього залежить від найбільшої навантаження на пропускну здатність. Якщо ви вже передаєте часті фрагменти відео, оптимізація даних про нечасті керування є менш вартістю. Якщо у вас є часті невеликі передачі (можливо температура), є сенс мінімізувати накладні витрати в передачі, але, можливо, просто дозування передач настільки ж добре.