Pull to refresh

Comments 22

Тема интересная и нужная, спасибо!
Вот бы еще для любителей бинарных протоколов и не-любителей изобретать их с нуля рассказать про protobuf, msgpack, bson и другие.
Вы только что дали мне идею для следующей статьи :) Благодарю
На мой взгляд писать о пользе текстовой форме представления данных и убеждать читателя не имеет смысла. Потому что есть книга Реймонда «Искусство программирования для UNIX», там очень подробно и доходчиво поясняется о том когда же все-таки нужно данные представлять в бинарном\текстовом виде.
Думаю Вам вполне достаточно привести ссылку на эту книгу и привести примеры, как уже указывалось выше:
>>protobuf, msgpack, bson и другие"
Навязывать свою точку зрения на то, в какой области применять тот или иной вид и в мыслях не было :) А вот сузить тему статьи до разбора одного-двух известных решений из мира «любителей бинарных протоколов» — это может оказаться интересным и полезным.
Тогда ещё ASN.1 не забудьте :) Хотя это само по себе тема для целой статьи…
Включите в планы EDIFACT. Это что-то среднее между бинарными протоколами и XML. Эдакий малосимвольный XML.
Пришлось как-то разбирать дамп общения неких программ в этом формате: приятного было мало :)
Тема бинарный/символьный религиозна так же, как и тема windows/linux.
Но это не значит, что статья не годная. Статья хорошая! Я бы ещё немного оформил и всемиоченьлюбимых картинок парочку вкрутил.
Каюсь, неразбавленная картинками статья действительно несколько теряет в читабельности и усвояемости. Приму на заметку!
Какое-то у Вас сильно странное и довольно надуманное деление на символьные и бинарные протоколы. Вот скажите, HTTP это символьный или бинарный?

Если из символьных на ум приходит на ум только то, что на базе json и xml, то подумайте об smtp и pop :)

Так называемые «символьные» протоколы происходят от терминалов с подмножеством 7-8-битного алфавита, а «бинарные» от куска памяти со структурой на Си, засунутого как есть в буфер ввода-вывода. Но в действительности сущность данных куда более сложна.

Рекомендую для начала посмотреть, как обходятся с интами в protobuf, очень полезно для освобождения разума от байтовых рамок :)
>>Вот скажите, HTTP это символьный или бинарный?
Это не «символьный» это текстовая форма представления данных, так правильней называть. Да, вы правы Json, XML, pop, smtp это все — текстовое.

Основное преимущество текстовой формы, это облегчение отладки систем! Программист может «поговорить» с системой!

В случае бинарного представления, вам надо написать конвертер из ваших текстовых приказов в бинарную форму, либо взять Hex-редактор и «нафигачить» перед подачей на вход системы. А это уже значительно сложнее, чем просто написать текст!
На самом деле тут все немного сложнее. Основной смысл «текстовых» протоколов это сохранять понятийную область. Точнее сказать, в некоторых случаях просто нет особой надобности «компилировать» данные в не текстовый вид, а потом обратно.

Программисту нет проблем взять себе удобный инструмент для «разговора». Например, когда вы смотрите свой json в каком-нибудь fierbug'е, то можете не задумываться, что на самом деле он пришел сюда в gzip'е, строки в нем были оформлены в таком виде,
"\u0430\u0431\u0432", а от вас на сервер он уходил вообще в urlencode форме (но это уже из области извращений).

Еще одна особенность текстовых протоколов незаслуженно забывается — они как правило line buffered. Поток информации разбивается на удобоваримые куски, причем, удобство человека здесь как раз не причем.
На самом деле тут все немного сложнее. Основной смысл «текстовых» протоколов это сохранять понятийную область. Точнее сказать, в некоторых случаях просто нет особой надобности «компилировать» данные в не текстовый вид, а потом обратно.

Программисту нет проблем взять себе удобный инструмент для «разговора». Например, когда вы смотрите свой json в каком-нибудь fierbug'е, то можете не задумываться, что на самом деле он пришел сюда в gzip'е, строки в нем были оформлены в таком виде,
"\u0430\u0431\u0432", а от вас на сервер он уходил вообще в urlencode форме (но это уже из области извращений).

Еще одна особенность текстовых протоколов незаслуженно забывается — они как правило line buffered. Поток информации разбивается на удобоваримые куски, причем, удобство человека здесь как раз не причем.
Сорри, как-то оно раздвоилось тут…
Соглашаясь с EvilsInterrupt, добавлю следующее: протокол, ориентированный на передачу данных, абстрагированных от машинной интерпретации (числа в строковом представлении, строковые константы вместо численных энумераторов и т.д.), но более понятных в таком виде человеку, как раз и подпадает под моё определение «текстового».
HTTP изначально символьный, но в теле сообщения содержит бинарные блоки. SMTP/POP вообще символьные, в них бинарные блоки кодируются в символьные строки UUE/Base64

protobuf вообще знатное извращение. =) Мне больше bencode нравится, его можно глазами читать
UFO just landed and posted this here
Сжатие конечно позволит уменьшить избыточность текстовых протоколов, но приведет к еще большему отставанию по скорости обработки :)
С отрывом от прикладной задачи писать о протоколе высокого уровня — довольно спорная затея, так как тема слишком широка. Для одних протоколов важна скорость, для других важна синхронизация событий, для третьих маршрутизация, для четвертых надежность и т. д. Все эти требования противоречат друг другу, поэтому выбор протокола — широкое поле для компромиссов и творчества. После прочтения статьи понятнее, по крайней мере, ничего не стало =).

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

Первейший из них — это тип передаваемых данных — fast datapath или slow datapath. Fast подразумевает, что нагрузка при передаче и приёме такова, что мы жертвуем всеми второстепенными вопросами (например, читаемостью) ради скорости. slow — означает, что мы можем посвятить сколько-то времени каждому сообщению/потоку.

Дальше — realtime/non-realtime, ordered/unordered, с подтвержением/без, с защитой от повторов/без.
Дальше — допустимые типы данных и структуры.

А мелочи, типа порядка байт, уже обсуждаются на последнем этапе.
Главное, что бы для штатных задач не городили монстров. Когда работаешь с > 10 разными форматами, становится очень грустно каждый раз, когда видишь очередной текстовый формат класса «значение X ищите с 42го столбца по 52й, с забивкой пустых знакомест символом % справа». Хочется сразу таким дизайнерам пожелать остаток жизни сверять подобные файлы с 100к+ записей каждый день (и каждый день нового формата). :)
контрольная сумма дла заголовка — это верно.
при этом желательно чтобы контрольная сумма сообщения была частью заголовка…
Sign up to leave a comment.

Articles