где 824377344 соответствует 0x31230000 (номер пpoгрaммы, присвоенный ей в листинге 16.1). В том же листинге мы присвоили программе номер версии 1. Обратите внимание, что сервер готов принимать запросы от клиентов по протоколам TCP и UDP и клиент может выбирать, какой из этих протоколов он будет использовать при создании дескриптора клиента (последний аргумент clnt_create в листинге 16.2).
3. Клиент запускается и вызывает clnt_create. Аргументами (листинг 16.2) являются имя узла или IP-адрес сервера, номер пpoгрaммы, номер версии и строка, указывающая протокол связи. Запрос RPC направляется пpoгрaммe отображения портов узла сервера (для этого сообщения обычно используется протокол UDP), причем запрашивается информация об указанной версии указанной программы с указанным протоколом. В случае успеха номер порта сохраняется в дескрипторе клиента для обработки всех последующих вызовов RPC через этот дескриптор.
В листинге 16.1 мы присвоили нашей программе номер 0x31230000. 32-разрядные номера пpoгрaмм подразделяются на группы, приведенные в табл. 16.1.
Таблица 16.1. Диапазоны номеров программ для Sun RPC
| Номер программы | Описание |
|---|---|
| 0x00000000–0x1fffffff | Определена Sun |
| 0x20000000–0x3fffffff | Определена пользователем |
| 0x40000000–0x5fffffff | Временная (для приложений, написанных заказчиком) |
| 0x60000000–0xffffffff | Зарезервированы |
Пpoгрaммa rpcinfо выводит список программ, зарегистрированных в системе. Другим источником информации о пpoгрaммax RPC могут являться файлы с расширением .х в каталоге /usr/inciude/rpcsvc.
По умолчанию серверы, созданные с помощью 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 \000\000\020. rstatd superuser
100001 3 ticlts \000\000\020. rstatd superuser
100001 4 ticlts \000\000\020. rstatd superuser
Четвертое поле содержит адреса XTI, причем 128×256+11 = 32779, и данное значение является временным номером порта, присвоенным этой концевой точке UDP.