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

Ответ 1

Ключевыми факторами являются:

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

Текстовые форматы (XML, CSV и т.д.) имеют тенденцию быть очень сжимаемыми. Бинарные форматы имеют тенденцию быть менее сжимаемыми, но с самого начала имеют меньше "растраченных" бит.

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

Удачи!

Ответ 7

Из веб-сайта YAML:

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

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

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

Ответ 8

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

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

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