Linux API. Исчерпывающее руководство

Разные компьютерные архитектуры используют различные правила представления типов данных. Например, в целом числе байты могут следовать от старшего к младшему и наоборот; к тому же количество байтов, выделяемых для типов int или long, может варьироваться в зависимости от компьютера. Ввиду этих отличий при передаче данных между гетерогенными компьютерами, соединенными по сети, нужно применять некое универсальное представление, не зависящее от архитектуры. Мы отметили, что для решения этой проблемы существуют разные стандарты маршалинга; а также описали методику, которая применяется во многих приложениях и состоит в переводе всех передаваемых данных в текстовый вид, где поля разделяются специальными символами (обычно символом новой строки).

Мы рассмотрели ряд функций для преобразования между строковыми представлениями IP-адресов (в IPv4 это десятичные числа, разделенные точками, а в IPv6 — шестнадцатеричная строка) и их двоичными эквивалентами. Хотя обычно более предпочтительным является использование имен узлов и служб, так как по сравнению с числами их легче запоминать; к тому же они остаются актуальными, даже если поменять соответствующие IP-адреса. Мы обсудили различные функции для перевода имен узлов и служб в их числовое представление (и наоборот). На сегодняшний день стандартной функцией для указанных операций является getaddrinfo(), но в имеющемся коде можно встретить ее устаревшие аналоги — gethostbyname() и getservbyname().

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

55.16. Упражнения

55.1. Функция readLine(), показанная в листинге 55.1, не очень эффективна при чтении больших объемов данных, поскольку для получения каждого символа требуется отдельный системный вызов. Более рациональным подходом было бы считывать символы блоками, записывать их в буфер и только потом извлекать их построчно. Такой интерфейс может состоять из двух функций. Первую из них можно назвать readLineBufInit(fd, &rlbuf); она инициализирует структуру данных, на которую указывает rlbuf. В этой структуре предусмотрено место для буфера с символами, информации о его размере и указателя на следующий «непрочитанный» символ в буфере. В нем также хранится копия файлового дескриптора, переданного в виде аргумента fd. Вторая функция, readLineBuf(&rlbuf), возвращает из буфера rlbuf следующую строку. При необходимости она может прочитать дополнительный блок данных из файлового дескриптора, сохраненного в структуре rlbuf. Реализуйте обе эти функции. Внедрите их в программы is_seqnum_sv.c (листинг 55.6) и is_seqnum_cl.c (листинг 55.7).

55.2. Измените программы is_seqnum_sv.c и is_seqnum_cl.c из листингов 55.6 и 55.7 так, чтобы в них использовались функции inetListen() и inetConnect(), представленные в листинге 55.9 (inet_sockets.c).

55.3. Напишите библиотеку для работы с сокетами домена UNIX. Ее программный интерфейс должен быть похож на тот, который применяется для сокетов интернет-домена в разделе 55.12. Перепишите программы us_xfr_sv.c (листинг 53.3) и us_xfr_cl.c (листинг 53.4) с использованием этой библиотеки.

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

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

56. Сокеты: архитектура сервера

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

56.1. Итерационные и параллельные серверы

Существуют две распространенные архитектуры сетевых серверов на основе сокетов:

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

• параллельная: сервер спроектирован для обслуживания нескольких клиентов одновременно.

В разделе 44.8 уже был представлен пример итерационного сервера на основе очередей FIFO.