UNIX: разработка сетевых приложений - Уильям Стивенс
Шрифт:
Интервал:
Закладка:
22.7. Параллельные серверы UDP
Большинство серверов UDP являются последовательными (iterative): сервер ждет запрос клиента, считывает запрос, обрабатывает его, отправляет обратно ответ и затем ждет следующий клиентский запрос. Но когда обработка запроса клиента занимает длительное время, желательно так или иначе совместить во времени обработку различных запросов.
Определение «длительное время» означает, что другой клиент вынужден ждать в течение некоторого заметного для него промежутка времени, пока обслуживается текущий клиент. Например, если два клиентских запроса приходят в течение 10 мс и предоставление сервиса каждому клиенту занимает в среднем 5 с, то второй клиент будет вынужден ждать ответа около 10 с вместо 5 с (если бы запрос был принят в обработку сразу же по прибытии).
В случае TCP проблема решается просто — требуется лишь породить дочерний процесс с помощью функции fork (или создать новый поток, что мы увидим в главе 23) и дать возможность дочернему процессу выполнять обработку нового клиента. При использовании TCP ситуация существенно упрощается за счет того, что каждое клиентское соединение уникально: пара сокетов TCP уникальна для каждого соединения. Но в случае с UDP мы вынуждены рассматривать два различных типа серверов.
1. Первый тип — простой сервер UDP, который читает клиентский запрос, посылает ответ и затем завершает работу с клиентом. В этом сценарии сервер, читающий запрос клиента, может с помощью функции fork породить дочерний процесс и дать ему возможность обработать запрос. «Запрос», то есть содержимое дейтаграммы и структура адреса сокета, содержащая адрес протокола клиента, передаются дочернему процессу в виде копии содержимого области памяти из функции fork. Затем дочерний процесс посылает свой ответ непосредственно клиенту.
2. Второй тип — сервер UDP, обменивающийся множеством дейтаграмм с клиентом. Проблема здесь в том, что единственный номер порта сервера, известный клиенту, — это номер заранее известного порта. Клиент посылает первую дейтаграмму своего запроса на этот порт, но как сервер сможет отличить последующие дейтаграммы этого клиента от запросов новых клиентов? Типичным решением этой проблемы для сервера будет создание нового сокета для каждого клиента, связывание при помощи функции bind динамически назначаемого порта с этим сокетом и использование этого сокета для всех своих ответов. При этом требуется, чтобы клиент запомнил номер порта, с которого был отправлен первый ответ сервера, и отправлял последующие дейтаграммы уже на этот порт.
Примером второго типа сервера UDP является сервер TFTP (Trivial File Transfer Protocol — упрощенный протокол передачи файлов). Передача файла с помощью TFTP обычно требует большого числа дейтаграмм (сотен или тысяч, в зависимости от размера файла), поскольку этот протокол отправляет в одной дейтаграмме только 512 байт. Клиент отправляет дейтаграмму на известный порт сервера (69), указывая, какой файл нужно отправить или получить. Сервер читает запрос, но отправляет ответ с другого сокета, который он создает и связывает с динамически назначаемым портом. Все последующие дейтаграммы между клиентом и сервером используют для передачи этого файла новый сокет. Это позволяет главному серверу TFTP продолжать обработку других клиентских запросов, приходящих на порт 69, в то время как происходит передача файла (возможно, в течение нескольких секунд или даже минут).
Если мы рассмотрим автономный сервер TFTP (то есть случай, когда не используется демон inetd), то получим сценарий, показанный на рис. 22.3. Мы считаем, что динамически назначаемый порт, связанный дочерним процессом с его новым сокетом, — это порт 2134.
Рис. 22.3. Процессы, происходящие на автономном параллельном UDP-сервере
Если используется демон inetd, сценарий включает еще один шаг. Вспомните из табл. 13.4, что большинство серверов UDP задают аргумент wait-flag как wait. В описании, которое следовало за рис. 13.4, мы сказали, что при указанном значении этого флага демон inetd приостанавливает выполнение функции select на сокете до завершения дочернего процесса, давая возможность этому дочернему процессу считать дейтаграмму, доставленную на сокет. На рис. 22.4 показаны все шаги.
Рис. 22.4. Параллельный сервер UDP, запущенный демоном inetd
Сервер TFTP, являясь дочерним процессом функции inetd, вызывает функцию recvfrom и считывает клиентский запрос. Затем он с помощью функции fork порождает собственный дочерний процесс, и этот дочерний процесс будет обрабатывать клиентский запрос. Затем сервер TFTP вызывает функцию exit, отправляя демону inetd сигнал SIGCHLD, который, как мы сказали, указывает демону inetd снова вызвать функцию select на сокете, связанном с портом UDP 69.
22.8. Информация о пакетах IPv6
IPv6 позволяет приложению определять до пяти характеристик исходящей дейтаграммы:
■ IPv6-адрес отправителя;
■ индекс интерфейса для исходящих дейтаграмм;
■ предельное количество транзитных узлов для исходящих дейтаграмм;
■ адрес следующего транзитного узла;
■ класс исходящего трафика.
Эта информация отправляется в виде вспомогательных данных с функцией sendmsg. Для сокета можно задать постоянные параметры, которые будут действовать на все отправляемые пакеты (раздел 27.7).
Для полученного пакета могут быть возвращены четыре аналогичных характеристики. Они возвращаются в виде вспомогательных данных с функцией recvmsg:
■ IPv6-адрес получателя;
■ индекс интерфейса для входящих дейтаграмм;
■ предельное количество транзитных узлов для входящих дейтаграмм.
■ класс входящего трафика.
На рис. 22.5 показано содержимое вспомогательных данных, о которых рассказывается далее.
Рис. 22.5. Вспомогательные данные для информации о пакете IPv6
Структура in6_pktinfo содержит либо IPv6-адрес отправителя и индекс интерфейса для исходящей дейтаграммы, либо IPv6-адрес получателя и индекс интерфейса для получаемой дейтаграммы:
struct in6_pktinfo {
struct in6_addr ipi6_addr; /* IPv6-адрес отправителя/получателя */
int ipi6_ifindex; /* индекс интерфейса для исходящей/получаемой дейтаграммы */
};
Эта структура определяется в заголовочном файле <netinet/in.h>, подключение которого позволяет ее использовать. В структуре cmsghdr, содержащей вспомогательные данные, элемент cmsg_level будет иметь значение IPPROTO_IPV6, элемент cmsg_type будет равен IPV6_PKTINFO и первый байт данных будет первым байтом структуры in6_pktinfo. В примере, приведенном на рис. 22.5, мы считаем, что между структурой cmsghdr и данными нет заполнения и целое число занимает 4 байта.
Чтобы отправить эту информацию, никаких специальных действий не требуется — нужно только задать управляющую информацию во вспомогательных данных функции sendmsg. Чтобы информация добавлялась ко всем отправляемым через сокет пакетам, необходимо установить параметр сокета IPV6_PKTINFO со значением in6_pktinfo. Возвращать эту информацию функция recvmsg будет, только если приложение включит параметр сокета IPV6_RECVPKTINFO.
Исходящий и входящий интерфейсы
Интерфейсы на узле IPv6 идентифицируются небольшими целыми положительными числами, как мы сказали в разделе 18.6. Вспомните, что ни одному интерфейсу не может быть присвоен нулевой индекс. При задании исходящего интерфейса ядро само выберет исходящий интерфейс, если значение ipi6_ifindex нулевое. Если приложение задает исходящий интерфейс для пакета многоадресной передачи, то любой интерфейс, заданный параметром сокета IPV6_MULTICAST_IF, заменяется на интерфейс, заданный вспомогательными данными (но только для данной дейтаграммы).
Адрес отправителя и адрес получателя IPv6
IPv6-адрес отправителя обычно определяется при помощи функции bind. Но если адрес отправителя поставляется вместе с данными, это может снизить непроизводительные затраты. Этот параметр также позволяет серверу гарантировать, что адрес отправителя ответа совпадает с адресом получателя клиентского запроса — некоторым клиентам требуется такое условие, которое сложно выполнить в случае IPv4 (см. упражнение 22.4).
Когда IPv6-адрес отправителя задан в качестве вспомогательных данных и элемент ipi6_addr структуры in6_pktinfo имеет значение IN6ADDR_ANY_INIT, возможны следующие сценарии: если адрес в настоящий момент связан с сокетом, он используется в качестве адреса отправителя; если в настоящий момент никакой адрес не связан с сокетом, ядро выбирает адрес отправителя. Если же элемент ipi6_addr не является неопределенным адресом, но сокет уже связался с адресом отправителя, то значением элемента ipi6_addr перекрывается уже связанный адрес, но только для данной операции вывода. Затем ядро проверяет, действительно ли запрашиваемый адрес отправителя является адресом направленной передачи, присвоенным узлу.
