Хоча справедливо сказати, що XML є багатослівним, це слід гартувати з усвідомленням того, що це багатослів’я не все «накладне» щодо змісту, оскільки воно інкапсулює семантику; це накладні витрати, що є симптоматичним для будь-якого протоколу, який підкреслює динаміку на відміну від статичної структури. Наприклад, HTML - це справді розслаблена форма XML, яка передає контент з динамічною структурою, структурою, яку можна вважати аспектом вмісту. Ви можете відрізнити зміст таблиці від самої таблиці, але той факт, що вміст є табличними даними з конкретними співвідношеннями, є невід’ємним змістом; якщо я просто взяв кожну клітинку і передавав все це однією довгою струною, ця структура та ці відносини вже відсутні, і тому я втратив інформацію, і чи не це вміст?
Розглянемо 8-байтне повідомлення, яке може становити деякі табуляційні дані. Якщо я використовую дуже статичний протокол, я міг би, як мінімум, передавати це без додаткових накладних витрат, просто визначивши такий протокол:
- Кожне повідомлення має рівно 8 байт, тому нам не потрібно вказувати довжину або включати будь-яку завершальну послідовність.
- Вісім байт завжди приймаються для позначення сітки 2 х 2, де кожна комірка містить 16-бітове значення.
Якщо всі мої повідомлення точно такі, використання XML, HTML або XMPP може вважатися нерозумним - я витрачаю пропускну здатність на структурні компоненти, які завжди однакові і заздалегідь визначені, і витрачаю відповідний час обчислення на обох кінцях, створюючи та аналізуючи їх. Мінімальна, належна HTML-сторінка, що містить лише 2 x 2 таблиці з парою символів у кожній комірці, ймовірно, має становити щонайменше 100 байт для розміщення форматування та протоколу накладних витрат.
Однак якщо не всі мої повідомлення саме такі, то уточнення, яке саме повідомлення може бути, не є буквальною частиною "корисного навантаження", але це необхідний компонент, змістовний. Я міг би зробити це лише з додатковими двома байтами і ввести набагато більше динамізму:
- Тепер повідомлення мають різну довжину, 0-255 байт, і перший байт вказує довжину.
- Існує (до) 256 кодів для різних заздалегідь визначених типів повідомлень, один з яких "2 х 2 таблиці", це другий байт.
Зараз мої 8 байт вмісту таблиці потребують 2 байти накладних витрат, але існує набагато ширший спектр можливостей щодо того, які види повідомлень можна надіслати за допомогою цього користувацького протоколу.
Це все ще ніде не наближене до можливостей сторінки HTML або специфікації простору імен XML (або їх набору, що по суті є XMPP ).
Отже, виходячи з цього, якщо в основному те, що ви робите, - це надсилання простих 8-байтних повідомлень, XMPP, ймовірно, надмірний. Однак не обов’язково так багато. Твердження про те, що "один обмін запитом / відповіддю для надсилання одного байта даних з IOT ЗВ'ЯЗАНОГО ПРИСТРОЮ на сервер становить понад 0,5 кБ", мені здається, поглядаючи на відповідний RFC , є потенційним перебільшенням (але nb, все Я поглянув на це, я ніколи не реалізував і не використовував XMPP). Я не сумніваюся, що ви могли побудувати приклад такого, але це, мабуть, не мінімальний приклад.
Оскільки протокол орієнтований на TCP, встановлення "потоку XML, кваліфікованого за допомогою простору імен" jabber: client ", потрібно вважати частиною повідомлення лише в тому випадку, коли ми займаємось одними справами - пристрій зв’язується з сервером, щоб надіслати 8 байт, надіслати дані, відключає. Якщо відносини є більш стійкими, що часто було б в контексті IoT, то можна припустити, що пристрій вже має встановлене з'єднання з пунктом призначення. У цьому випадку, якщо кінцевим пунктом призначення повідомлення є сервер (на відміну від іншого клієнта, на який сервер збирається передати повідомлення), накладні витрати протоколу потенційно мінімальні.
<message><body>8 bytes.</body></message>
Потворні 33 байти "накладних витрат". Тут варто зазначити, що XML - це текст, і тому, якщо ваші повідомлення часто є двійковими, то це стане набагато менш доречним, тому що ці дані потрібно кодувати (наприклад, до base64 ), що додає додаткові накладні та обчислювальні дані вимоги.
Отже, в кінцевому рахунку:
Чи має XMPP великі накладні витрати на пристрої IoT, що надсилають короткі, часті повідомлення?
Якщо існує стійкий зв’язок і повідомлення в основному неструктуровані, я не думаю, що так. Однак, якщо вам не потрібно те, що він пропонує (динамізм щодо структури), можливо, існують більш відповідні методології.
З огляду на це, якщо у нас є контекст, коли один центральний сервер обробляє та / або спирається на повідомлення між різними пристроями, навіть якщо те, що робить будь-який з цих пристроїв, завжди може бути простим і зрозумілим, протокол, який може інкапсулювати різноманітність повідомлень все ще буде корисною. Якщо клієнтський пристрій має обмежені ресурси, ми можемо жорстко кодувати велику частину протоколу, і загортання кожного повідомлення з цього кінця стає дуже простим завданням; Я вважаю, що багато IoT-пристроїв, що розгортають HTTP-сервери, роблять це (що є зворотною стороною "прості клієнти, складний сервер"). Ці сервери не можуть обробляти будь-який тип запиту HTTP (за винятком попередньо відформатованого відхилення) і мають дуже чітко визначений, цілеспрямований набір дій, які будуть робити, і відповіді, які вони надсилатимуть, але оскільки вони не менш функціонують правильно як HTTP-сервери,