Книга: UNIX: взаимодействие процессов

Inetd и серверы RPC

Inetd и серверы RPC

По умолчанию серверы, созданные с помощью rpcgen, могут вызываться сервером верхнего уровня inetd. Этот сервер описывается в разделе 12.5 [24]. Изучение содержимого заглушки сервера, создаваемой rpcgen, показывает, что при запуске функции main сервера она проверяет, является ли стандартный поток ввода конечной точкой XTI, и если так, то предполагается, что сервер был запущен демоном inetd.

После создания сервера RPC, который будет вызываться inetd, следует добавить информацию об этом сервере в файл /etc/inetd.conf. Туда помещаются следующие данные: имя программы RPC, поддерживаемые номера программ, протоколы и полное имя исполняемого файла сервера. В качестве примера мы приводим строку из конфигурационного файла Solaris:

rstatd/2-4 tli rpc/datagram_v wait root /usr/lib/netsvc/rstat/rpc.rstatd rpc.rstatd

Первое поле содержит имя пpoгрaммы (которому будет сопоставлен номер с помощью файла /etc/rpc); поддерживаются версии 2, 3 и 4. Следующее поле задает конечную точку XTI (или сокет), третье поле говорит о том, что поддерживаются все протоколы видимых дeйтaгрaмм. Если свериться с содержимым файла /etc/netconfig, мы узнаем, что таких протоколов два: UDP и /dev/clts. Глава 29 [24] описывает этот файл и адреса XTI. Четвертое поле (wait) указывает демону inetd на необходимость ожидания завершения этого сервера перед включением режима ожидания запроса клиента для конечной точки XTI. Все серверы RPC указывают атрибут wait в конфигурационном файле /etc/inetd.conf.

Следующее поле, root, указывает идентификатор пользователя, с которым будет выполняться пpoгрaммa. Последние два поля задают полное имя исполняемого файла пpoгрaммы и имя пpoгрaммы вместе с необходимыми аргументами командной строки (у данной пpoгрaммы они отсутствуют).

Демон inetd создаст конечные точки XTI и зарегистрирует их в программе отображения портов для соответствующих номеров пpoгрaмм и версий. Мы можем убедиться в этом с помощью rpcinfo:

solaris % rpcinfo | grep statd
100001 2 udp    0.0.0.0.128.11 rstatd superuser
100001 3 udp    0.0.0.0.128.11 rstatd superuser
100001 4 udp    0.0.0.0.128.11 rstatd superuser
100001 2 ticlts 000020.  rstatd superuser
100001 3 ticlts 000020.  rstatd superuser
100001 4 ticlts 000020.  rstatd superuser

Четвертое поле содержит адреса XTI, причем 128?256+11 = 32779, и данное значение является временным номером порта, присвоенным этой концевой точке UDP.

Когда дейтаграмма UDP поступает в порт 32779, демон inetd обнаруживает готовность этой дейтаграммы к обработке и вызывает fork, а затем exec для запуска программы /usr/lib/netsvc/rstat/rpc.rstatd. Перед вызовами fork и exec концевая точка XTI будет скопирована в дескрипторы 0, 1 и 2, а все прочие дескрипторы inetd будут закрыты (рис. 12.7 [24]). Демон inetd также прекратит слушать эту конечную точку XTI, не реагируя на запросы пользователей до тех пор, пока сервер (дочерний процесс по отношению к inetd) не завершит работу. Это поведение определяется атрибутом wait.

Предположим, что эта программа была создана с помощью rpcgen. Тогда она сможет распознать конечную точку XTI, подключенную к стандартному потоку ввода, и инициализировать ее как конечную точку сервера RPC. Это осуществляется вызовом функций RPC svc_tli_create и svc_reg, которые в данной книге не рассматриваются. Вторая функция (вопреки названию) не регистрирует сервер в программе отображения портов — это делается лишь однажды, при запуске сервера. Функция svc_run прочитает пришедшую дейтаграмму и вызовет соответствующую процедуру сервера для обработки запроса клиента.

В обычной ситуации серверы, запускаемые демоном inetd, обрабатывают один запрос клиента и завершают работу, после чего inetd переходит в режим ожидания следующего запроса. Для оптимизации работы системы серверы RPC, созданные rpcgen, ждут поступления нового запроса от клиента в течение некоторого времени (по умолчанию 2 минуты). В этом случае дейтаграмма обрабатывается уже запущенным сервером. Это исключает накладные расходы на вызов fork и exec при поступлении нескольких клиентских запросов подряд. По истечении периода ожидания сервер завершает работу, а демону inetd отсылается сигнал SIGCHLD, после чего он переходит в режим ожидания дейтаграмм по XTI.

Оглавление книги