Искусство программирования для Unix - Реймонд Эрик Стивен Страница 42

Наконец, необходимо отметить отличие между форматами файлов данных и конфигурационных файлов, которые часто используются для установки параметров запуска Unix-программ. Самое основное отличие заключается в том, что (за редкими исключениями, такими как конфигурационный интерфейс редактора GNU Emacs) программы обычно не изменяют свои конфигурационные файлы — информационный поток является односторонним (от файла, считываемого при запуске, к настройкам приложения). С другой стороны, форматы файлов данных связывают свойства с именованными ресурсами, и такие файлы считываются и записываются соответствующими приложениями. Конфигурационные файлы, как правило,

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

Исторически Unix обладает связанными, но различными наборами соглашений для данных двух видов представления. Соглашения для конфигурационных файлов рассматриваются в главе 10; в данной главе описываются только соглашения для файлов данных.

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

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

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

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

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

Генри Спенсер.

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

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

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

Джим Геттис.

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

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

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

Джим Геттис.

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

5.1.1. Учебный пример: формат файлов паролей в Unix

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

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

Пример 5.1. Пример файла паролей

games: *:12: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: / :

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