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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

С сайта YAML:

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

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

Так что JSON намного лучше так как это читаемый человеком и более эффективный ЯМЛ.

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

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

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