Читать онлайн «Искусство программирования для Unix». Страница 36

5.1. Важность текстовой формы представления

Каналы и сокеты передают двоичные данные так же, как текст. Однако есть важные причины, для того чтобы примеры, рассматриваемые в главе 7, были текстовыми: причины, связанные с рекомендацией Дуга Макилроя, приведенной в главе 1. Текстовые потоки являются ценным универсальным форматом, поскольку они просты для чтения, записи и редактирования человеком без использования специализированных инструментов. Данные форматы прозрачны (или могут быть спроектированы как таковые).

Кроме того, сами ограничения текстовых потоков способствуют усилению инкапсуляции. Препятствуя сложным формам представления с богатой, плотно закодированной структурой, текстовые потоки также препятствуют созданию программ, которые смешивают внутренние компоненты друг друга. Текстовые потоки также способствуют усилению инкапсуляции. Эта проблема рассматривается в главе 7 при обсуждении технологии RPC.

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

Плохим примером двоичных форматов в истории Unix был способ аппаратно-независимого чтения программой troff двоичного файла (предположительно в целях повышения скорости), содержащего информацию устройства. В первоначальной реализации данный двоичный файл генерировался из текстового описания способом, отчасти не пригодным для переноса на другие платформы. Столкнувшись с необходимостью быстро перенести ditroff на новую машину, я вместо того, чтобы переделывать двоичный материал, вырезал его и просто заставил ditroff читать текстовый файл. Тщательно созданный код чтения файла сделал потерю скорости незначительной.

Проектирование текстового протокола часто защищает систему в будущем, поскольку диапазоны в числовых полях не подразумеваются самим форматом. В двоичных форматах обычно определяется количество битов, выделенных для данного значения, и расширение таких форматов является трудной задачей. Например, протокол IPv4 допускает использование только 32-битового адреса. Для того чтобы увеличить размер до 128 бит (как это сделано в протоколе IPv6), требуется значительная реконструкция[50]. Напротив, если требуется ввести большее значение в текстовый формат, то его необходимо просто записать. Возможно, что какая-либо программа не способна принимать значения в данном диапазоне, однако, программу обычно проще модифицировать, чем изменять все данные, хранящиеся в этом формате.

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

Аналогичная для SMTP- или HTTP-подобных текстовых протоколов проблема заключается в том, что они требуют большой полосы пропускания и их синтаксический анализ производится медленно. Наименьший X-запрос занимает 4 байта, а наименьший HTTP-запрос занимает около 100 байт. X-запросы, включая транспортные издержки, могут быть выполнены с помощью приблизительно 100 инструкций; разработчики Apache (Web-сервера) гордо заявляют, что сократили выполнение запроса до 7000 инструкций. Решающим фактором на выходе для графических приложений становится полоса пропускания. Аппаратное обеспечение разрабатывается таким образом, что в настоящее время шина графической платы является бутылочным горлышком для небольших операций, поэтому любой протокол, если он не должен быть еще худшим бутылочным горлышком, должен быть очень компактным. Это предельный случай.

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

Кроме того, проектирование компактных двоичных форматов значительно затруднено, когда необходимо сделать их четко расширяемыми. С данной проблемой столкнулись разработчики X Window.

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

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

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

В приведенном ниже примере содержатся некоторые случайно выбранные строки.

games:*:2:100:games:/usr/games:

gopher:*:13:30:gopher:/usr/lib/gopher-data:

ftp:*:14:50:FTP User:/home/ftp:

esr:0SmFuPnH5JINs:23:23:Eric S. Raymond:/home/esr:

nobody:*:99:99:Nobody:/:

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

В действительности, перспективы сохранения пространства посредством двоичного кодирования почти полностью исчезают, если известна фактическая семантика данных. Значения числового идентификатора пользователя (третье поле) и идентификатора группы (четвертое поле) являются целыми числами, поэтому на большинстве машин двоичное представление данных идентификаторов заняло бы по крайней мере 4 байта и было бы длиннее текста для всех значений до 999. Это можно проигнорировать и предположить наилучший случай, при котором значения числовых полей находятся в диапазоне 0-255.

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

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

Действительно, необходимо быть осторожным, чтобы не вставить символ двоеточия в какое-либо текстовое поле. Хорошей практикой является создание такого кода записи файла, который предваряет вставляемые символы двоеточия знаком переключения (escape character), а код чтения файла затем интерпретирует данный символ. В традиции Unix для этих целей предпочтительно использовать символ обратной косой черты.