Уильям Стивенс - UNIX: разработка сетевых приложений
- Название:UNIX: разработка сетевых приложений
- Автор:
- Жанр:
- Издательство:Питер
- Год:2007
- Город:Санкт-Петербург
- ISBN:5-94723-991-4
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Уильям Стивенс - UNIX: разработка сетевых приложений краткое содержание
Новое издание книги, посвященной созданию веб-серверов, клиент-серверных приложений или любого другого сетевого программного обеспечения в операционной системе UNIX, — классическое руководство по сетевым программным интерфейсам, в частности сокетам. Оно основано на трудах Уильяма Стивенса и полностью переработано и обновлено двумя ведущими экспертами по сетевому программированию. В книгу включено описание ключевых современных стандартов, реализаций и методов, она содержит большое количество иллюстрирующих примеров и может использоваться как учебник по программированию в сетях, так и в качестве справочника для опытных программистов.
UNIX: разработка сетевых приложений - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Реализация 4.3BSD упростила ситуацию, предоставив суперсервер ( superserver ) Интернета — демон inetd
. Этот демон может применяться серверами, использующими TCP или UDP, и не поддерживает других протоколов, таких как доменные сокеты Unix. Демон inetd
решает две вышеупомянутые проблемы.
1. Он упрощает написание процессов демонов, поскольку обрабатывает большинство подробностей запуска. Таким образом устраняется необходимость вызова нашей функции daemon_init
для каждого сервера.
2. Этот демон позволяет одиночному процессу ( inetd
) ждать входящие клиентские запросы ко множеству служб (вместо одного процесса для каждой службы). Это сокращает общее число процессов в системе.
Процесс inetd
сам становится демоном, используя технологии, которые мы изложили при описании функции daemon_init
. Затем он считывает и обрабатывает файл конфигурации, обычно файл /etc/inetd.conf
. Этот файл задает, какие службы должен обрабатывать суперсервер, а также что нужно делать, когда приходит запрос к одной из этих служб. Каждая строка содержит поля, показанные в табл. 13.4. Вот несколько строк в качестве примера:
ftp stream tcp nowait root /usr/bin/ftpd ftpd -l
telnet stream tcp nowait root /usr/bin/telnetd telnetd
login stream tcp nowait root /usr/bin/rlogind rlogind -s
tftp dgram udp wait nobody /usr/bin/tftpd tftpd -s /tftpboot
Действительное имя сервера всегда передается в качестве первого аргумента программе, выполняемой с помощью функции exec
.
Таблица 13.4. Поля файла inetd.conf
Поле | Описание |
---|---|
service-name | Должен быть в /etc/services |
socket-type | stream (TCP) или dgram (UDP) |
Protocol | Должен быть в /etc/protocols; либо tcp, либо udp |
wait-flag | Обычно nowait для TCP и wait для UDP |
login-name | Из /etc/password; обычно root |
server-program | Полное имя программы для вызова exec |
server-program-arguments | Аргументы программы для вызова exec |
Таблица и приведенные строки — это только пример. Большинство производителей добавили демону inetd свои собственные функции. Примером может служить возможность обрабатывать серверы вызовов удаленных процедур (RPC) в дополнение к серверам TCP и UDP, а также возможность обрабатывать другие протоколы, отличные от TCP и UDP. Полное имя для функции exec и аргументы командной строки сервера, очевидно, зависят от приложения.
Флаг wait-flag может быть достаточно труден для понимания. Он указывает, собирается ли демон, запускаемый inetd, взять на себя работу с прослушиваемым сокетом. Сервисы UDP лишены деления на прослушиваемые и принятые сокеты, и потому практически всегда создаются с флагом wait-flag, равным wait. Сервисы TCP могут вести себя по-разному, но чаще всего для них указывается флаг wait-flag со значением nowait.
Взаимодействие IPv6 с файлом /etc/inetd.conf зависит от производителя. Иногда в качестве поля protocol указывается tcp6 или udp6, чтобы подчеркнуть, что для сервера должен быть создан сокет IPv6. Некоторые разрешают использовать значения protocol, равные tcp46 и udp46, если сервер готов принимать соединения по обоим протоколам. Специальные названия протоколов обычно не включаются в файл /etc/protocols.
Иллюстрация действий, выполняемых демоном inetd
, представлена на рис. 13.1.

Рис. 13.1. Действия, выполняемые демоном inetd
1. При запуске демон читает файл /etc/inetd.conf
и создает сокет соответствующего типа (потоковый или дейтаграммный сокет) для всех служб, заданных в файле. Максимальное число серверов, которые может обрабатывать демон 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.
Интервал:
Закладка: