Протокол обмена данными со встроенными устройствами

Общая идея

Устройства, ограниченные в вычислительных возможностях на самом деле умеют делать довольно много. И делать это они умеют довольно быстро.

Современные форматы обмена информации, принятые в рынке PC просто неэффективны и не подходят для таких задач. Но с упорством, достойным лучшего применения разработчики продолжают тащить в рынок микроконтроллеров JSON, YAML, XML, HTTP и т.п. чушь.

Устройству должно быть удобно формировать ответ и читать команды. С этой новости я начинаю публикацию мыслей относительно того, как это могло бы быть сделано.

Передача сообщения

Мне кажется, что не имеет смысла пытаться решить все вопросы сразу. Пусть те форматы сообщений, которые я буду описывать, будут наивными и простыми. Если будущие задачи потребуют шифрования и т.п. усложнения, пусть они будут реализованы поверзу простых протоколов.

Запрос-ответ

Не имеет смысла реализовывать концепцию “запрос-ответ”, как и любую другую синхронную технологию. Я убеждён, что наиболее рациональной системой является обмен, основанный на технологии: запрос, ожидание ответа (трап) — асинхронный ответ.

Если приложение по умолчанию не будет рассчитывать на немедленный ответ, картина радикальным образом меняется.

Структура данных

Совершенно непонятно, почему до сих пор не получила распространения идеология SNMP на встраиваемых устройствах. Если обдумать обмен данными любьыми сколько-нибудь сложными устройствами, становится понятно, что их обмен не бывает основан на предположении, что хотя бы одна из сторон не обладает в полной мере сведениями о протоколе обмена.

Зачем в этом случае вкладывать в обмен информацию, которую не следует вкладывать? Например, имена передаваемых полей информации и т.п. сведения? Не проще иметь некий аналог MIB, если нужны имена, и простое представление в виде последовательности чисел, если речь идёт и о запросе конкретных данных?

Предположим, что мы запрашиваем сведения о температуре у холодильника. Наш запрос может быть всего-лишь несколько байт длинной, поскольку узлы дерева информации каждого устройства представлены числами, и даже наши команды могут быть представлены простыми числами.

Это просто разбирать. Это просто составлять. Это просто расширять.

Поскольку числа, представленные таким образом, естественным образом ограничены, можно легко представить себе разделитель в виде точки, который бы отделял одни числа от других:

1.212.012

Здесь точка отделяет 2 12, в виде отдельного многопозиционного числа. Например, в данном случае указывается, что будет всего 2 знака и искомое число получается у нас 12.

В целом идея такова: следует делать протокол обмена таким, чтобы его было удобно читать байт за байтом. Это делает анализатор простым, а поведение программы предсказуемым.