Уильям Стивенс - UNIX: разработка сетевых приложений

Рис. 13.2. Дескрипторы демона inetd в тот момент, когда приходит запрос на порт 21 TCP

Запрос на соединение направляется на порт 21 TCP; новый присоединенный сокет создается функцией accept.

На рис. 13.3 показаны дескрипторы в дочернем процессе после вызова функции fork, после того как дочерний процесс закрывает все остальные дескрипторы, кроме дескрипторов присоединенного сокета.

Рис. 13.3. Дескрипторы демона inetd в дочернем процессе

Следующий шаг для дочернего процесса — подключение присоединенного сокета к дескрипторам 0, 1 и 2 и последующее закрытие присоединенного сокета. При этом мы получаем дескрипторы, изображенные на рис. 13.4.

Рис. 13.4. Дескрипторы демона inetd после выполнения функции dup2

Затем дочерний процесс вызывает функцию exec, и, как сказано в разделе 4.7, во время выполнения функции execвсе дескрипторы обычно остаются открытыми, поэтому реальный сервер, на котором выполняется функция exec, использует любой из дескрипторов 0, 1 и 2 для взаимодействия с клиентом. Эти дескрипторы должны быть единственными открытыми на стороне сервера дескрипторами.

Описанный нами сценарий относится к ситуации, при которой файл конфигурации задает в поле wait-flagзначение nowaitдля сервера. Это типично для всех служб TCP и означает, что демону inetdне нужно ждать завершения его дочернего процесса, перед тем как он примет другое соединение для данной службы. Если приходит другой запрос на соединение для той же службы, он возвращается родительскому процессу, как только тот снова вызовет функцию select. Шаги 4, 5 и 6, перечисленные выше, выполняются снова, и новый запрос обрабатывается другим дочерним процессом.

Задание флага waitдля дейтаграммного сервиса изменяет шаги, выполняемые родительским процессом. Флаг указывает на то, что демон inetdдолжен ждать завершения своего дочернего процесса, прежде чем снова вызвать функцию selectдля определения готовности этого сокета UDP для чтения. Происходят следующие изменения:

1. После выполнения функции forkв родительском процессе сохраняется идентификатор дочернего процесса. Это дает возможность родительскому процессу узнать, когда завершается определенный дочерний процесс, анализируя значение, возвращаемое функцией waitpid.

2. Родительский процесс отключает способность сокета выполнять последующие функции select, сбрасывая соответствующий бит в наборе дескрипторов с помощью макроса FD_CLR. Это значит, что дочерний процесс завладевает сокетом до своего завершения.

3. Когда завершается дочерний процесс, родительский процесс уведомляется об этом с помощью сигнала SIGCHLD, и обработчик сигналов родительского процесса получает идентификатор завершающегося дочернего процесса. Он снова включает функцию selectдля соответствующего сокета, устанавливая бит для этого сокета в своем наборе дескрипторов.

Причина, по которой дейтаграммный сервер должен завладевать сокетом, пока он не завершит работу, лишая тем самым демон inetdвозможности выполнять функцию selectна этом сокете для проверки готовности его для чтения (в ожидании другой дейтаграммы клиента), в том, что для сервера дейтаграмм существует только один сокет, в отличие от сервера TCP, у которого имеется прослушиваемый сокет и по одному присоединенному сокету для каждого клиента. Если демон inetdне отключил чтение на сокете дейтаграмм и, допустим, родительский процесс ( inetd) завершил выполнение перед дочерним, дейтаграмма от клиента все еще будет находиться в приемном буфере сокета. Это приводит к тому, что функция selectснова сообщает, что сокет готов для чтения, и демон inetdснова выполняет функцию fork, порождая другой (ненужный) дочерний процесс. Демон inetdдолжен игнорировать дейтаграммный сокет до тех пор, пока он не узнает, что дочерний процесс прочитал дейтаграмму из приемного буфера сокета. Демон inetdузнает, что дочерний процесс закончил работу с сокетом, путем получения сигнала SIGCHLD, указывающего на то, что дочерний процесс завершился. Подобный пример мы показываем в разделе 22.7.

Пять стандартных служб Интернета, описанных в табл. 2.1, обеспечиваются самим демоном inetd(см. упражнение 13.2).

Поскольку функцию acceptдля сервера TCP вызывает демон inetd(а не сам сервер), реальный сервер, запускаемый демоном inetd, обычно вызывает функцию getpeernameдля получения IP-адреса и номера порта клиента. Вспомните рис. 4.9, где мы показывали, что после выполнения вызовов forkи exec(что выполняет демон inetd) у реального сервера есть единственный способ получить идентификацию клиента — вызвать функцию getpeername.

Демон inetdобычно не используется для серверов, работающих с большими объемами данных, в особенности почтовыми серверами и веб-серверами. Например, функция sendmailобычно запускается как стандартный параллельный сервер, как мы отмечали в разделе 4.8. В этом режиме стоимость порождения процесса для каждого клиентского соединения равна стоимости функции fork, тогда как в случае сервера TCP, активизированного демоном inetd, — стоимости функций forkи exec. Веб-серверы используют множество технологий для минимизации накладных расходов при порождении процессов для обслуживания клиентов, как мы покажем в главе 30.

В листинге 13.3 показана функция daemon_inetd, которую мы можем вызвать с сервера, запущенного демоном inetd.

Листинг 13.3. Функция daemon_inetd для придания свойств демона процессу, запущенному демоном inetd

//daemon_inetd.c

1 #include "unp.h"

2 #include

3 extern int daemon_proc; /* определено в error.c */

4 void

5 daemon_inetd(const char *pname, int facility)

6 {

7 daemon_proc = 1; /* для наших функций err_XXX() */

8 openlog(pname, LOG_PID, facility);

9 }

Эта функция тривиальна по сравнению с daemon_init, потому что все шаги выполняются демоном inetdпри запуске. Все, что мы делаем, — устанавливаем флаг daemon_procдля наших функций ошибок (см. табл. Г.1) и вызываем функцию openlogс теми же аргументами, что и при вызове функции daemon_init, представленной в листинге 13.1.