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

Стивенс Уильям Ричард
Шрифт:

19 exit(0);

20 }

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

tcp_listen
и
accept
. Эти шаги выполняются демоном
inetd
, и мы ссылаемся на соединение TCP, используя нулевой дескриптор (стандартный поток ввода). Во-вторых, исчез бесконечный цикл
for
, поскольку сервер активизируется по одному разу для каждого клиентского соединения. После предоставления сервиса клиенту сервер завершает свою работу.

Вызов функции getpeername

11-14
Поскольку мы не вызываем функцию
tcp_listen
, мы не знаем размера структуры адреса сокета, которую она возвращает, а поскольку мы не вызываем функцию
accept
, то не знаем и адреса протокола клиента. Следовательно, мы выделяем буфер для структуры адреса сокета, используя нашу константу
MAXSOCKADDR
и вызываем функцию
getpeername
с нулевым дескриптором в качестве первого аргумента.

Чтобы выполнить этот пример в нашей системе Solaris, сначала мы присваиваем службе имя и порт, добавляя следующую строку в

/etc/services
:

mydaytime 9999/tcp

Затем добавляем строку в

/etc/inetd.conf
:

mydaytime stream tcp nowait andy

/home/andy/daytimetcpsrv3 daytimetcpsrv3

(Мы разбили длинную строку на более короткие.) Мы помещаем выполняемый код в заданный файл и отправляем демону

inetd
сигнал
SIGHUP
, сообщающий ему, что нужно заново считать файл конфигурации. Следующий шаг — выполнить программу
netstat
, чтобы проверить, что на порте TCP 9999 создан прослушиваемый сокет:

solaris % netstat -na | grep 9999

*.9999 *.* 0 0 49152 0 LISTEN

Затем мы запускаем сервер с другого узла:

linux % telnet solaris 9999

Trying 192.168.1.20...

Connected to solaris.

Escape character is '^]'.

Tue Jun 10 11:04:02 2003

Connection closed by foreign host.

Файл

/var/amd/messages
(в который, как указано в нашем файле
/etc/syslog.conf
, должны направляться наши сообщения с аргументом
facility=LOG_USER
) содержит запись:

Jun 10 11:04:02 solaris daytimetcpsrv3[28724]: connection from 192.168.1.10.58145

13.7. Резюме

Демоны — это процессы, выполняемые в фоновом режиме независимо от управления с терминалов. Многие сетевые серверы работают как демоны. Все выходные данные демона обычно отправляются демону

syslogd
при помощи вызова функции
syslog
. Администратор полностью контролирует все, что происходит с этими сообщениями, основываясь на том, какой демон отправил данное сообщение и насколько оно серьезно.

Чтобы запустить произвольную программу и выполнять ее в качестве демона, требуется пройти несколько шагов: вызвать функцию

fork
для запуска в фоновом режиме, вызвать функцию
setsid
для того, чтобы создать новый сеанс POSIX и стать главным процессом сеанса, снова вызвать функцию
fork
, чтобы избежать перехода в режим управления с терминала, изменить рабочий каталог и маску режима создания файла и закрыть все ненужные файлы. Наша функция
daemon_init
выполняет все эти шаги.

Многие серверы Unix запускаются демоном

inetd
. Он осуществляет все необходимые шаги по превращению процесса в демон, и при запуске действительного сервера открывается сокет для стандартных потоков ввода, вывода и сообщений об ошибках. Это позволяет нам опустить вызовы функций
socket
,
bind
,
listen
и
accept
, поскольку все эти шаги выполняются демоном
inetd
.

Упражнения

1. Что произойдет в листинге 13.2, если мы отложим вызов функции

daemon_init
до завершения обработки аргументов командной строки и функция
err_quit
будет вызвана до того, как программа станет демоном?

2. Как вы думаете, какие из 10 серверов, перечисленных в табл. 2.1 (учитываются версии TCP и UDP для каждой из пяти служб, управляемых демоном

inetd
), реализуются с помощью вызова функции fork, а какие не требуют этой функции?

3. Что произойдет, если мы создадим сокет UDP, свяжем порт 7 с сокетом (стандартный эхо-сервер в табл. 2.1) и отправим дейтаграмму UDP-серверу

chargen
?