и создает сокет соответствующего типа (потоковый или дейтаграммный сокет) для всех служб, заданных в файле. Максимальное число серверов, которые может обрабатывать демон
inetd
, зависит от максимального числа дескрипторов, которые он может создать. Каждый новый сокет добавляется к набору дескрипторов, который будет использован
при вызове функции
select
.
2. Для каждого сокета вызывается функция
bind
, задающая заранее известный порт для сервера и универсальный IP-адрес. Этот номер порта TCP или UDP получается при вызове функции
getservbyname
с полями
service
– name и
protocol
из файла конфигурации в качестве аргументов.
3. Для сокетов TCP вызывается функция
listen
, так что принимаются входящие запросы на соединение. Этот шаг не выполняется для дейтаграммных сокетов.
4. После того как созданы все сокеты, вызывается функция
select
, ожидающая, когда какой-либо из сокетов станет готов для чтения. Вспомните (раздел 6.3), что прослушиваемый сокет TCP становится готов для чтения, когда новое соединение готово быть принятым с помощью функции
accept
, а сокет UDP становится готов для чтения, когда приходит дейтаграмма. Демон
inetd
большую часть времени блокирован в вызове функции
select
, ожидая, когда сокет станет готов для чтения.
5. При указании флага
nowait
для сокетов TCP вызывается функция
accept
сразу же, как только дескриптор сокета становится готов для чтения.
6. Демон
inetd
запускает функцию
fork
, и дочерний процесс обрабатывает запрос клиента. Это аналогично стандартному параллельному серверу (см. раздел 4.8).
Дочерний процесс закрывает все дескрипторы, кроме дескриптора, который он обрабатывает: новый присоединенный сокет, возвращаемый функцией
accept
для сервера TCP, или исходный сокет UDP. Дочерний процесс трижды вызывает функцию
dup2
, подключая сокет к дескрипторам 0, 1 и 2 (стандартные потоки ввода, вывода и сообщений об ошибках). Исходный дескриптор сокета затем закрывается. При этом в дочернем процессе открытыми остаются только дескрипторы 0, 1 и 2. Если дочерний процесс читает из стандартного потока ввода, он читает из сокета, и все, что он записывает в стандартный поток вывода или стандартный поток сообщений об ошибках, записывается в сокет. Дочерний процесс вызывает функцию
getpwnam
, чтобы получить значение поля
login-name
, заданного в файле конфигурации. Если это не поле root, дочерний процесс становится указанным пользователем при помощи функций
setgid
и
setuid
. (Поскольку процесс
inetd
выполняется с идентификатором пользователя, равным 0, дочерний процесс наследует этот идентификатор пользователя при выполнении функции
fork
, поэтому он имеет возможность стать любым пользователем по своему выбору.)
Теперь дочерний процесс вызывает функцию
exec
, чтобы выполнить соответствующую программу сервера(поле
server-program
) для обработки запроса, передавая аргументы, указанные в файле конфигурации.
7. Если сокет является потоковым сокетом, родительский процесс должен закрыть присоединенный сокет (как наш стандартный параллельный сервер). Родительский процесс снова вызывает функцию
select
, ожидая, когда следующий сокет станет готов для чтения.
Чтобы рассмотреть более подробно, что происходит с дескрипторами,
на рис. 13.2 показаны дескрипторы демона
inetd
в момент прихода нового запроса на соединение от клиента FTP.
Рис. 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
для соответствующего сокета, устанавливая бит для этого сокета в своем наборе дескрипторов.