Наиболее эффективный формат для передачи данных на встроенные устройства и с них

Question

Мне сложно выбрать формат, в котором мой сервер и мои конечные точки будут взаимодействовать.
Я рассматриваю:

• JSON
• YAML Слишком сложно разобрать
• CSV
• Google Protobufs
• Двоичная упаковка / распаковка (без использования casting / memset / memcpy для обеспечения переносимости)
• Некоторая форма DSL
• Любое другое предложение, которое у вас может быть

Мои критерии упорядочены от самых важных к наименьшим:

1. Что проще всего разобрать?
2. Какой самый быстрый для анализа?
3. Какой из них имеет наименьшее количество байтов?
4. Что может иметь наиболее читаемые сообщения?
5. Что может быть легче зашифровано?
6. Что может быть легче сжать?

РЕДАКТИРОВАТЬ, чтобы уточнить:

• Являются ли передачи данных двунаправленными? Да.
• Что такое физический транспорт? Ethernet.
• Данные форматируются как пакеты или потоки? Оба, но обычно пакеты.
• Сколько оперативной памяти имеют конечные точки? Наименьшее возможное количество, в зависимости от выбранного формата.
• Насколько велики ваши данные? Такой большой, каким должен быть. Я не буду получать огромные наборы данных.
• Есть ли у конечной точки ОСРВ? номер

Answer 1

Ключевые факторы:

• Какими возможностями обладают ваши клиенты?(Например, можете ли вы выбрать анализатор XML с полки - не исключая большинство из них по соображениям производительности? Можете ли вы сжимать пакеты на лету?)
• Какова сложность ваших данных («плоская»)или глубоко структурированный?)
• Вам нужны высокочастотные обновления?Частичные обновления?

По моему опыту:

Простой текстовый протокол (который классифицируется как DSL) с интерфейсом

string RunCommand(string commandAndParams)
// e.g. RunCommand("version") returns "1.23"

упрощает многие аспекты: отладку, ведение журнала и трассировку, расширение протокола и т. Д. Наличие простого терминала / консоли для устройства неоценимо для отслеживания проблем, выполнения тестов и т. Д.

Давайте обсудим ограничениеподробно, в качестве ориентира для других форматов:

• Клиенту необходимо запустить микро-парсер.Это не так сложно, как может показаться (ядро моей «библиотеки микро-синтаксического анализатора» - 10 функций с общим количеством строк кода около 200), но базовая обработка строк должна быть возможной
• Плохо написанный синтаксический анализатор - большойповерхность атаки.Если устройства являются критическими / чувствительными, или ожидается, что они будут работать в неблагоприятной среде, внедрение требует предельной осторожности.(это верно и для других протоколов, но быстро взломанный синтаксический анализатор текста легко ошибиться)
• Накладные расходы.Может быть ограничено смешанным текстовым / двоичным протоколом или base64 (с накладными расходами 37%).
• Задержка.При типичной задержке в сети вам не понадобится много маленьких команд, помогает какой-то способ пакетных запросов и их возвратов.
• Кодирование.Если вам нужно передать строки, которые не могут быть представлены в ASCII, и вы не можете использовать что-то вроде UTF-8 для этого на обоих концах, преимущество текстового протокола быстро падает.

Я бы использовал двоичный протокол только в том случае, если устройство запрашивает его, возможности обработки устройства безумно низкие (скажем, USB-контроллеры с 256 байтами ОЗУ) или ваша пропускная способность сильно ограничена.Большинство протоколов, с которыми я работал, используют это, и это неприятно.

Google protBuf - это подход, который несколько упрощает бинарный протокол.Хороший выбор, если вы можете запускать библиотеки на обоих концах и иметь достаточно свободы для определения формата.

CSV - это способ упаковки большого количества данных в легко анализируемый формат, так что это расширение текстового формата.Это очень ограничено по структуре, хотя.Я бы использовал это, только если вы знаете, что ваши данные подходят.

XML / YAML /... Я бы использовал, только если вычислительная мощность не является проблемой, полоса пропускания либо не 'Это проблема, или вы можете сжать на лету, и данные имеют очень сложную структуру.JSON кажется немного легче для накладных расходов и требований синтаксического анализатора, может быть хорошим компромиссом.

Answer 2

Прежде всего, посмотрите, какие существующие библиотеки вы можете найти.Даже если формат трудно анализировать, предварительно написанная библиотека может сделать формат намного более привлекательным.Самый простой формат для анализа - это формат, для которого у вас уже есть анализатор.

Скорость синтаксического анализа обычно лучше всего подходит для двоичных форматов.Одним из самых быстрых методов является использование «плоского» двоичного формата (вы читаете в буфере, приводите указатель на буфер как указатель на структуру данных и получаете доступ к данным в буфере через структуру данных).Никакого реального «разбора» не требуется, поскольку вы передаете (по существу) двоичный дамп области памяти.

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

«Читаемый» является субъективным.Читается кем?Простые текстовые форматы, такие как XML и CSV, легко читаются людьми.Плоские двоичные изображения легко читаются на машинах.

Процедуры шифрования обычно обрабатывают данные, подлежащие сжатию, как кусок двоичных данных (они вообще не пытаются его интерпретировать), поэтому шифрование должно применяться одинаково хорошо кданные любого формата.

Текстовые форматы (XML, CSV и т. д.), как правило, являются очень сжимаемыми.Двоичные форматы, как правило, менее сжаты, но для начала имеют меньше «потерянных» битов.

По моему опыту, у меня были наилучшие результаты со следующим:

• CSV -Лучше всего, когда данные в предсказуемом, согласованном формате.Также полезно при взаимодействии с языком сценариев (где текстовый ввод / вывод может быть проще, чем двоичный ввод / вывод).Легко генерируется / интерпретируется вручную.
• Плоский двоичный файл - наилучший вариант при переносе структуры данных (POD) из одного места в другое.Для достижения наилучших результатов упакуйте структуру, чтобы избежать проблем с различными компиляторами, использующими разные отступы.
• Пользовательский формат - обычно лучшие результаты, поскольку разработка пользовательского формата позволяет сбалансировать гибкость, накладные расходы и удобочитаемость.К сожалению, разработка собственного формата с нуля может оказаться гораздо более сложной, чем кажется.

Answer 3

Обычно в этих случаях стоит настроить формат данных для устройства. Например, в зависимости от ограничений, с которыми вы сталкиваетесь в плане сети или размера хранилища, вы можете выбрать потоковое сжатие или предпочесть полное сжатие. Кроме того, тип данных, которые вы хотите сохранить, является важным фактором.

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

Я знаю, что не даю вам однозначного ответа, но я думаю, что такого общего вопроса нет.

Answer 4

Ответ на ваш первый вопрос во многом зависит от того, что вы пытаетесь сделать. Из тегов, прикрепленных к вашему вопросу, я понял, что ваши конечные точки - это встроенные системы, а ваш сервер - это некий тип ПК. Парсировать XML на ПК легко, но во встроенной системе это немного сложнее. Вы также не упоминаете, является ли ваше сообщение двунаправленным или нет. Если в вашем случае конечные точки только передают данные на сервер, а не наоборот, XML может работать хорошо. Если сервер передает данные в конечные точки, тогда CSV или собственный двоичный формат, вероятно, будет легче проанализировать в конечной точке. И CSV, и XML легко читаются человеком.

• Являются ли передачи данных двунаправленными?
• Что такое физический транспорт? (например, RS-232, Ethernet, USB?)
• Данные форматируются как пакеты или потоки?
• Сколько оперативной памяти имеют конечные точки? Насколько велики ваши данные?
• Есть ли у конечной точки ОСРВ?

Answer 5

CSV выполнит ваши желания раньше, чем решение на основе XML. Очень легко разобрать, от одной до двух десятков строк кода. Затем вы добавляете, что означают термины / поля, которые вам понадобятся для любого решения. Затраты CSV очень незначительны: некоторые запятые и кавычки по сравнению с XML-решением, в котором вы часто найдете больше тегов и синтаксиса XML, чем реальное мясо / данные, десятки или сотни байтов часто записываются для 8- или 32-битных значений. Предоставленный CSV также имеет накладные расходы, если вы думаете, что требуется три символа (байта) для представления одного 8-битного значения (шестнадцатеричная запятая с шестнадцатеричной запятой) по сравнению с двоичным. Несжатое XML-решение с его объемами будет потреблять значительно большую пропускную способность и объем хранилища поверх громоздких библиотек, используемых для создания, анализа и, возможно, сжатия / распаковки. CSV будет легче читать, чем двоичный файл, и, конечно, часто будет проще, чем XML, поскольку XML очень многословен, и вы не можете видеть все связанные данные на одном экране одновременно. У каждого есть доступ к хорошему инструменту для работы с электронными таблицами, gnumeric, openoffice, ms office, что делает CSV намного проще для чтения / использования, графический интерфейс уже есть.

Хотя нет общего ответа, вам нужно сделать системную инженерию по этому вопросу. Возможно, вы захотите использовать JSON / XML на стороне хоста или большого компьютера и конвертировать в какой-то другой формат, например двоичный, для передачи, а затем на встроенной стороне, возможно, вам вообще не нужен ASCII и не нужно тратить энергию на возьмите двоичные данные и просто используйте их. Я также не знаю вашего определения встроенного, я полагаю, поскольку вы говорите о форматах ascii, это не микроконтроллер с ограниченными ресурсами, а, вероятно, встроенный linux или другая операционная система. С точки зрения системной инженерии, что именно требуется встроенной системе и в какой форме? На один уровень выше того, какие ресурсы у вас есть, и, как следствие, в какой форме вы хотите хранить эти данные во встроенной системе, хочет ли встроенная система просто брать предварительно отформатированный двоичный файл и просто передавать байты прямо на любое периферийное устройство, которое данные были предназначены для? в этом случае встроенный драйвер может быть очень тупым / простым / надежным, и основная часть работы и отладки выполняется на стороне хоста, где имеется много ресурсов и ресурсов для форматирования данных. Я бы стремился к минимальному форматированию и накладным расходам, если бы вам пришлось включить библиотеку для ее анализа, я бы, вероятно, не использовал ее. но я часто работаю со встроенными системами с ограниченными ресурсами без операционной системы.

Answer 6

Недавно я разработал свою собственную схему сериализации для связи с мобильными устройствами, только чтобы мой внутренний выпуск совпал с публичным объявлением о протобуфах Google. Это было немного разочарованием, так как протокол Google был немного лучше. Я бы посоветовал разобраться в этом.

Например, взгляните на простые числа. Синтаксический анализ JSON, XML или CSV требует синтаксического анализа чисел ASCII. ASCII получает около 3,3 бит на байт; protobuf получает вас 7. Для разбора ASCII требуется поиск разделителей и математика, а protobuf - просто битая обработка.

Конечно, сообщения не будут читаться напрямую с помощью protobuf. Но визуализатор быстро взломан вместе; тяжелая работа уже сделана Google.

Answer 7

с сайта YAML :

И JSON, и YAML стремятся быть людьми удобочитаемые форматы обмена данными. Однако JSON и YAML имеют разные приоритеты . Передовой дизайн JSON цель простота и универсальность. Таким образом, J SON тривиально генерировать и разобрать, за счет уменьшения человека Читаемость. Он также использует самый низкий информационная модель общего знаменателя, обеспечение любых данных JSON может быть легко обрабатывается каждым современным программированием окружающая среда.

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

Так что JSON намного лучше, так как он более читабелен и эффективнее YAML.

Answer 8

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

Инструменты конвертации могут дать вам лучший компромисс, если данные не очень часто читаются человеком, но если вам нужно предоставить инструменты конвертации, это будет дополнительной поддержкой (что, если они не будут работать на последняя версия Windows, Linux и т. д.).

В моей ситуации CSV доказывает разумный компромисс для моего приложения из-за большого количества легко доступных редакторов CSV (например, Excel) и только из-за необходимости предоставить документацию о том, как создавать / редактировать файлы CSV. CSV не является полностью определенным стандартом, это боль, но RFC4180 является хорошим стандартом CSV, к которому нужно стремиться.

http://tools.ietf.org/html/rfc4180

Как сказал другой ответ, я не могу дать вам четкий ответ, но, как вы определили, это будет компромиссом между ремонтопригодностью системы каждым человеком и скоростью и размером встроенного решения (т.е. оно работает !).

Удачи!