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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

С веб-сайта YAML :

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

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

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

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

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

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