В Sun RPC используется свой стандарт именования программ. Каждой программе присваивается 32-разрядный номер программы, 32-разрядный номер версии и 32-разрядный номер процедуры. Каждый узел с сервером RPC должен выполнять программу отображения портов в фоновом режиме (RPCBIND). Серверы RPC привязывают временные порты TCP и UDP к своим процедурам, а затем регистрируют эти порты в программе отображения портов, указывая номера программ и версий. При запуске клиент RPC связывается с программой отображения портов узла, где запущен сервер RPC, и выясняет номер нужного ему порта, а затем связывается с самим сервером по протоколам TCP или UDP.

По умолчанию клиенты RPC не предоставляют аутентификационной информации и серверы RPC обрабатывают все приходящие запросы. Это аналогично написанию собственного приложения клиент-сервер с использованием сокетов или XTI. В Sun RPC предоставляются три дополнительные формы аутентификации: аутентификация Unix (предоставляется имя узла клиента, идентификатор пользователя и группы), аутентификация DES (основанная на криптографии с секретным и открытым ключом) и аутентификация Kerberos.

Понимание стратегии тайм-аутов и повторных передач пакета RPC важно при использовании RPC (как и любой формы сетевого программирования). При использовании надежного транспортного протокола, такого, как TCP, клиенту RPC нужно использовать только общий тайм-аут, поскольку потеря пакетов или прием лишних копий целиком обрабатываются на транспортном уровне. Когда используется ненадежный транспортный протокол, такой как UDP, пакет RPC использует тайм-аут повтора в дополнение к общему тайм-ауту. Идентификатор транзакций используется клиентом RPC для проверки ответа на соответствие отправленному запросу. 

Любой вызов процедуры может быть отнесен к группе «ровно один», «не более чем один» или «не менее чем один». Для локальных вызовов этот вопрос можно не принимать во внимание, но при использовании RPC эту разницу следует понимать. Следует также понимать различия между идемпотентными и неидемпотентными процедурами.

Sun RPC — это большой пакет, и мы лишь вкратце обсудили особенности его использования. Тем не менее сведений, приведенных в этой главе, должно быть достаточно для написания приложений целиком. Использование rpcgen скрывает многие детали и упрощает кодирование. Документация Sun описывает различные уровни кодирования RPC — упрощенный интерфейс, верхний уровень, средний уровень, уровень экспертов и низкий уровень, но эти категории достаточно бессмысленны. Количество функций в библиотеке RPC — 164, они могут быть разделены следующим образом:

■ 11 auth_ (аутентификация);

■ 26 clnt_ (клиентские);

■ 5 pmap_ (доступ к программе отображения портов);

■ 24 rpc_ (общего назначения);

■ 44 svc_ (серверные);

■ 54 xdr_ (преобразования XDR).

Для сравнения отметим, что интерфейсы сокетов и XTI содержат по 25 функций, а интерфейсы дверей, очередей сообщений Posix и System V, семафоров и разделяемой памяти содержат по 10 функций. 15 функций используются для работы с потоками в стандарте Posix, 10 — для работы с условными переменными. 11 функций используются для работы с блокировками чтения-записи Posix и одна при работе с блокировкой записей fcntl.

1. При запуске сервер регистрируется в программе отображения портов. Что происходит при завершении сервера, например, клавишей завершения программы с терминала? Что произойдет, если на этот сервер впоследствии придет запрос от клиента?

2. Клиент взаимодействует с сервером RPC по протоколу UDP, и кэш не включен. Клиент посылает запрос на сервер, но серверу требуется 20 секунд до отправки ответа. Клиент посылает запрос повторно через 15 секунд, что приводит к повторному запуску процедуры сервера. Что произойдет со вторым ответом сервера?

3. Тип XDR string всегда кодируется в значение длины и последовательность символов. Что произойдет, если мы напишем char с[10] вместо string s<10>?

4. Измените максимальный размер string в листинге 16.11 со 128 на 10 и запустите программу write. Что произойдет? Уберите ограничение длины и сравните файл data_xdr.с с тем, который был создан, когда длина была ограничена. Что изменилось?

5. Измените третий аргумент в вызове xdrmem_create (размер буфера) в листинге 16.13 на 50 и посмотрите, что произойдет.

6. В разделе 16.5 мы описали включение кэша повторных ответов при использовании протокола UDP. Мы можем сказать, что протокол TCP имеет свой собственный кэш такого рода. О чем мы говорим и как велик этот кэш у протокола TCP? (Подсказка: как протокол TCP определяет, что принята копия полученных ранее данных?)

7. Есть пять полей, уникально идентифицирующих каждую запись в кэше сервера. В каком порядке следует их сравнивать, чтобы минимизировать количество сравнений?

8. При просмотре передаваемых пакетов с помощью tcpdump в примере из раздела 16.5, где использовался TCP, мы узнаем, что размер запроса 48 байт, а размер ответа 32 байт (без заголовков TCP и IPv4). Получите этот размер из рисунка 16.3. Каков был бы размер при использовании UDP вместо TCP?

9. Может ли клиент RPC в системе, не поддерживающей потоки, вызвать процедуру сервера, скомпилированную с поддержкой потоков? Что можно сказать о различии в передаваемых аргументах, о котором говорилось в разделе 16.2? 

10. В программе read из листинга 16.19 мы выделяли место под буфер, в который считывался файл, и этот буфер содержал указатель vstring_arg. Но где хранится строка, на которую указывает vstring_arg? Измените программу так, чтобы проверить ваше предположение.

11. Sun RPC определяет нулевую процедуру как процедуру с номером 0 (по этой причине мы всегда начинали нумерацию процедур с 1, как в листинге 16.1). Более того, любая заглушка сервера, созданная rpcgen, автоматически определяет эту процедуру (в чем вы можете легко убедиться, посмотрев текст любой заглушки, созданной для одного из наших примеров). Нулевая процедура не принимает никаких аргументов и ничего не возвращает. Часто она используется для проверки работы сервера и измерения скорости передачи пакетов на сервер и обратно. Но если мы посмотрим на заглушку клиента, мы увидим, что в ней не содержится заглушки для этой процедуры. Посмотрите в документации описание функции clnt_call и используйте ее для вызова нулевой процедуры для любого сервера этой главы.