Должен ли я использовать XML или Binary для отправки данных с сервера на клиент?

Question

У меня есть два отдельных приложения - одно клиентское (в C #), одно серверное (в C ++). Они должны обмениваться данными в форме «структур», и ~ около 1 МБ данных в минуту отправляется с сервера на клиент.

Что лучше использовать - XML ​​или мой собственный двоичный формат?

С XML:

• Перевод XML в структуру с использованием синтаксического анализатора будет медленным, я полагаю? («хорошо», но: загрузить парсер, загрузить XML, разобрать)
• Другой вариант - синтаксический анализ XML с помощью регулярных выражений (плохо!)

С двоичным кодом:

• компактные размеры данных
• нет необходимости в метаинформации, такой как теги;
• но структуры не могут быть легко изменены, чтобы приспособить новые структуры / новых членов в структурах в будущем;
• нет необходимости в преобразовании текста (XML) в бинарный (struct), поэтому его быстрее получить и "собрать" в структуру)

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

Answer 1

1 МБ данных в минуту - это очень мало, если у вас разумное сетевое соединение.

Существуют другие варианты выбора между двоичным и XML - другие читаемые человеком форматы сериализации текста, такие как JSON.

Когда дело доходит до двоичного файла, у вас нет проблем с версиями - такие технологии, как Буферы протокола (я пристрастен: я работаю на Google, и у меня перенесены с PB на C # ), явно разработаны с учетом обратной и прямой совместимости. Существуют и другие двоичные форматы, такие как Thrift .

.

Если вы беспокоитесь о производительности, вы должны действительно измерить ее. Я почти уверен, что мой телефон мог бы достаточно быстро проанализировать 1 МБ XML, чтобы в этом случае это не было проблемой ... в основном решите, что вас больше всего беспокоит, с точки зрения:

• Простота кода
• Interoperability
• Производительность по процессору
• Сетевой трафик
• Обратная / прямая совместимость
• Удобочитаемость формата "по проводам"

Это все уравновешивающее действие, но вы должны решить, какой вес придать каждому из этих факторов.

Answer 2

Как вы заявили, XML (немного) медленнее, но гораздо более гибок и надежен. Я бы работал с XML, пока не возникнет проверенная проблема с производительностью.

Вам также следует взглянуть на ProtoBuff в качестве альтернативы.

И после вашего обновления любые требования к мультиязычности, кроссплатформенности и кросс-версии сильно отличаются от двоичного форматирования.

Answer 3

Если у вас есть приложения .NET на обоих концах, используйте Windows Communication Foundation . Это позволит вам отложить принятие решения до времени развертывания, поскольку оно поддерживает двоичную и XML-сериализацию.

Answer 4

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

Также даже минимальное (быстрое) сжатие XML может существенно снизить нагрузку на провод.

Answer 5

Хорошим моментом для XML была бы совместимость. У вас есть другие клиенты, которые также имеют доступ к вашему серверу?

Прежде чем использовать собственный двоичный формат или выполнять регулярные выражения для XML ... Рассматривали ли вы пространство имен сериализации в .NET? Существуют двоичные форматеры, SOAP-форматеры, а также XmlSerialization.

Answer 6

Не забывайте, что то, что большинство людей воспринимают как XML, это XML, сериализованный как текст. Вместо этого он может быть преобразован в двоичный код. Это то, что netTcpBinding и другие подобные привязки делают в WCF. Информационный набор XML выводится как двоичный файл, а не как текст. Это все еще XML, просто в двоичном виде.

Answer 7

Вы не сказали, находятся ли они на одной машине или нет. Я полагаю, нет.

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

XML очень многословный, YAML или JSON намного меньше

Answer 8

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

Answer 9

Текст / XML

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

бинарная

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

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