Это привлекло мое внимание недавно, когда я нашел удивительное видео на Youtube:
Майкл Э. Андерсон: Сравнение методов обмена сообщениями для IoT, OpenIoTSummit, Linux Foundation .
Слайды для его выступления доступны здесь
На слайде 26 и 41 минуте видео он обсуждает, как (позвольте мне перефразировать):
Операторы сотовой связи предпочитают, чтобы их потребители IoT использовали сообщения типа HTML , XML или JSON, поскольку они потребляют больше данных. Больше данных означает, что они могут брать с потребителей больше денег за услугу.
Я понимаю, что много проприетарных протоколов, а именно. SigFox , Wireless HART или Z Wave имеют более низкую скорость передачи данных, и отправка громоздких данных через такие носители может быть дорогостоящим делом.
Вопрос
Существуют ли другие легкие форматы сообщений, которые используются для использования в проприетарных протоколах, что делает их экономически эффективными решениями для нынешних и будущих потребителей IoT? (Снято в темноте: какой-то формат, называемый легким XML, HTML или JSON, где-то лежит?)
Может быть, что-то вроде CBOR используется или может быть использован?
источник
Ответы:
Вы спрашиваете о протоколе или формате сообщения ? Мы часто неправильно используем термин «протокол», когда имеем в виду формат данных. Я делаю это сам, часто потому, что различие не всем понятно.
Протоколы обмена сообщениями, используемые в IoT, имеют тенденцию быть достаточно компактными, по крайней мере, в большей степени, чем протокол HTTP, и предлагают важные функции, важные для обмена сообщениями (сеансы, управление потоком, надежность и т. Д.). Формат сообщения - это данные в сообщении, которые отправляются. Я предполагаю, что это то, о чем вы спрашиваете.
Самый компактный формат сообщений - это тщательно продуманный двоичный формат. Он часто используется в сценариях с низкой пропускной способностью, когда вы хотите отправить несколько байтов и точно знать, как выглядят эти байты. Для больших сообщений недостатки существенны и, как правило, их следует избегать любой ценой.
Я прошел детальную оценку многих вариантов сериализации данных. Я ожидал, что protobuf, messagepack будет довольно компактным, чем они и были. Однако моей второй проблемой был поиск библиотек, которые обслуживались и были доступны на разных платформах, включая C на устройстве.
Удивительно, но формат, в котором я остановился, был сжатый GZIP файл JSON. Его легко реализовать и понять, он работает везде, и с данными, которые я использовал, был примерно таким же или меньше, чем другие методы.
Также имейте в виду, что если у вас есть безопасный канал, такой как TLS, вы все равно будете использовать кусок данных (> 6 КБ) при рукопожатиях TLS.
Несколько лет назад я ожидал, что такой формат, как буферы протокола, будет доминировать, но на самом деле ничего особенного не произошло. Вероятно, из-за легкости, с которой json может быть записан и проанализирован (и сжат). Мне нравится внешний вид Flatbuffers , но преимущество больше в скорости разбора, чем в компактности.
Поскольку вы находитесь на стадии расследования, я предлагаю вам написать немного кода для каждого, используя данные, типичные для вашей ситуации, и провести некоторые сравнения. Наличие точных данных при запуске помогает подтвердить ваш выбор.
источник
Большим преимуществом формата на основе разметки является то, что вы сохраняете гибкость в выборе того, какие данные вы будете передавать. Это чрезвычайно важно в развивающейся экосистеме, где вы ожидаете, что услуга будет развиваться в течение нескольких лет развития.
Хотя хорошо закодированная структура двоичных данных будет эффективной для передачи, вам необходимо как минимум заранее решить, как будет выглядеть эта структура. Когда позже вы поймете, что даже одно поле нуждается в расширении, вы застряли. Даже развернуть обновление протокола сложно, так как вы не можете устаревать старую кодировку до тех пор, пока не будет обновлена каждая конечная точка.
Это говорит о том, что оптимальным подходом является смешивание минималистических пакетов и кодирования на основе разметки (используя последний в качестве запасного варианта). Значение этого зависит от самой высокой пропускной способности. Если вы уже передаете частые фрагменты размером с видео, оптимизация редких контрольных данных не имеет смысла. Если у вас частые небольшие передачи (возможно, температура), имеет смысл минимизировать накладные расходы при передаче, но, возможно, просто пакетная передача так же хороша.
источник