Действительно ли протоколы двоичной синхронной передачи данных мертвы? [закрытый]

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

Facebook, Last.fm и Evernote используют бинарный протокол Thrift .

Двоичные протоколы не умерли. Во многих случаях гораздо эффективнее отправлять двоичные данные.

WCF поддерживает двоичное кодирование с использованием TCP. http://msdn.microsoft.com/en-us/library/ms730879.aspx

Параллель с языками программирования, вероятно, очень актуальна.

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

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

Кроме того, в отличие от языков программирования, где есть сильные стимулы «получить удар по производительности» в обмен на дополнительную простоту, скорость разработки и т. Д., способность структурировать обмен данными по уровням делает сложность и «бинарность» "нижних уровней достаточно прозрачны для уровня приложения . Например, пока получаемые сообщения SOAP в порядке, приложению не нужно знать, что они были эффективно сжаты для передачи по сети.

Я действительно рад, что вы подняли этот вопрос, поскольку использование небинарных протоколов многократно увеличилось с момента появления XML. Десять лет назад можно было увидеть практически все, кто рекламировал свое «соответствие» коммуникациям на основе XML. Однако этот подход, один из нескольких подходов к бинарным протоколам, имеет много недостатков.

Одно из значений, например, читаемость. Но читабельность важна для отладки, когда люди должны читать транзакцию. Они очень неэффективны по сравнению с двоичными передачами. Это связано с тем, что XML сам по себе является двоичным потоком, который необходимо преобразовать с помощью другого уровня в текстовые фрагменты («токены»), а затем обратно в двоичный код с содержащимися данными.

Другой ценностью, которую нашли люди, была расширяемость. Но расширяемость может быть легко сохранена, если номер версии протокола для двоичного потока используется в начале транзакции. Вместо отправки тегов XML можно было отправлять двоичные индикаторы. Если номер версии неизвестен, то принимающая сторона может загрузить «словарь» этой неизвестной версии. Этот словарь может быть, например, файлом XML. Но загрузка словаря - это разовая операция, а не каждая отдельная транзакция!

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

И последнее, но не менее важное: я даже слышал, как люди говорят, что XML - это хороший способ преодолеть типы двоичных систем с прямым порядком байтов и прямым порядком байтов.Например, компьютеры Sun против компьютеров Intel. Но это неверно: если обе стороны могут принимать XML (ASCII) правильным образом, несомненно, обе стороны могут правильно принимать двоичный код, поскольку XML и ASCII также передаются в двоичном формате .......

Надеюсь, вы найди это интересное чтение!

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

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

Многие текстовые протоколы реализованы таким образом, что синтаксический анализатор не имеет основы для вывода, сколько еще данных необходимо, прежде чем будет получена логическая единица (XML и JSON могут предоставить минимально необходимые байты для завершения, но не может дать значимых оценок). Это означает, что синтаксическому анализатору, возможно, придется периодически уступать коду приема сокета, чтобы получить больше данных. Это нормально, если ваши сокеты находятся в режиме блокировки, но не так просто, если это не так. Обычно это означает, что все состояние парсера должно храниться в куче, а не в стеке.

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

В некоторых приложениях всегда будет существовать потребность в двоичных протоколах, например, при передаче данных с очень низкой пропускной способностью. Но у текстовых протоколов есть огромные преимущества. Например, я могу использовать Firebug, чтобы легко увидеть, что именно отправляется и принимается при каждом HTTP-вызове моего приложения. Удачи в этом с бинарным протоколом :)

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

Некоторые бинарные протоколы, которые я видел в дикой природе для Интернет-приложений

• Буферы протокола Google , которые используются для внутренней связи, но также например, синхронизация закладок Google Chrome
• Flash AMF , которая используется для связи с приложениями Flash и Flex.И Flash, и Flex имеют возможность обмениваться данными через REST или SOAP, однако формат AMF намного более эффективен для Flex, как показывают некоторые тесты

Are бинарные протоколы мертвы?

Два ответа:

1. Будем надеяться.
2. Нет.

По крайней мере, двоичный протокол лучше, чем XML, который обеспечивает всю читаемость двоичного протокола в сочетании с всей эффективностью меньшей эффективности, чем хорошо спроектированный протокол ASCII.

Неужто это полностью зависит от приложения? До сих пор было два общих типа примеров: ответы, связанные с xml / html, и видео / аудио. Один предназначен для «совместного использования», как отметил Джонатон, а другой - для эффективной передачи данных (и без Matrix Vision «чтение» фильма никогда не было бы полезным, как чтение HTML-документа).

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

Конечно, я бы сказал, что они не мертвы.

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

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

Подключите любую библиотеку для разбора XML/JSON/*, которую вы хотите использовать, выясните структуру информации и вырежьте интересующие вас фрагменты данных.