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

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

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

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

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

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

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

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

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

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

в моих опытах, я имел самые лучшие результаты с следующий:

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

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

нет общего ответа, хотя вам нужно сделать свою системную инженерию на этом. Вы можете очень хорошо пожелать иметь 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сын тривиален для генерации и parse, за счет сокращения человека удобочитаемость. он также использует самый низкий информационная модель общего знаменателя, обеспечение любых данных JSON может быть легко обработано каждым современным программированием окружающая среда.

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

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

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

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

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