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