Читаем Linux API. Исчерпывающее руководство полностью

В нашем примере все клиенты отправляют серверу свои запросы с помощью единой серверной очереди FIFO. Общеизвестное имя очереди (/tmp/seqnum_sv) определяется в заголовочном файле в листинге 44.6. Данное имя — постоянное, поэтому все клиенты знают, как соединиться с сервером. (В примере очередь FIFO создается в каталоге /tmp, поскольку это позволяет запускать программы без изменений в большинстве систем. Но, как отмечается в разделе 38.7, создание файлов в публичных каталогах, доступных для записи, таких как /tmp, чревато различными проблемами с безопасностью и в реальных приложениях является нежелательным.)

При работе с клиент-серверными приложениями мы будем постоянно сталкиваться с понятием «общеизвестный адрес» (или имя), с помощью которого сервер становится доступным для клиентов. Это один из механизмов, позволяющий клиентам определять местонахождение сервера. Еще один вариант заключается в предоставлении некоего DNS-сервера, в котором можно регистрировать различные сервисы, предоставляемые другими серверами. Когда клиенту нужно узнать местоположение сервиса, он связывается с DNS-сервером. Благодаря такому решению процедура размещения серверов становится более гибкой, хотя для этого необходимо проделать некую дополнительную работу. Естественно, в таком случае клиенты и серверы должны знать, где находится сам DNS-сервер; обычно он привязан к общеизвестному адресу.

Однако для отправки ответов всем клиентам недостаточно единственной очереди FIFO, поскольку клиенты стали бы за нее соперничать и, возможно, читать ответные сообщения друг друга вместо своих собственных. Таким образом, каждый клиент создает уникальную очередь FIFO, с помощью которой сервер доставляет ему свой ответ. При этом сервер должен знать, как найти данную очередь. Одним из решений проблемы является генерирование клиентом пути к своей очереди и передача этого пути вместе с запросом. Как вариант, клиент и сервер могут задействовать соглашение относительно построения пути к очереди FIFO; в таком случае вместе с запросом клиент будет отправлять информацию, необходимую для определения данного пути. Именно это решение используется в нашем примере. Имя каждой клиентской очереди формируется по шаблону (CLIENT_FIFO_TEMPLATE), который состоит из пути с идентификатором клиентского процесса. Применение идентификатора процесса упрощает генерирование имени, уникального для каждого конкретного клиента.

На рис. 44.6 показано, как наше приложение использует очереди FIFO для взаимодействия серверного и клиентского процессов.

Заголовочный файл (см. листинг 44.6) описывает форматы запросов, передающиеся от клиентов к серверу, и ответов, которые сервер возвращает клиентам.

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

• Каждое сообщение заканчивается символом-разделителем, таким как символ новой строки (примером подобного подхода является функция readLine() из листинга 55.1). В нашем случае это значит одно из двух: либо данный символ не должен встречаться в сообщениях, либо нужно его экранировать. Например, слеш плюс символ новой строки могут обозначать настоящий перевод строки в сообщениях, а сам слеш можно представить как \\. Одним из недостатков такого подхода является то, что сервер должен перебирать данные в очереди FIFO байт за байтом, пока не найдет символ-разделитель.

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

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