TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
Перед активизацией процедуры входные данные сохраняются как входные_параметры. Если процедура завершается успешно, полученные результаты сохраняются в выходных параметрах. По завершении код возврата указывает на успешность работы процедуры.
RPC работает аналогичным образом. Локальная система посылает запрос вызова на удаленный сервер. Запрос идентифицирует процедуру и получает входные параметры. Удаленный сервер выполняет процедуру. По завершении работы удаленный сервер формирует ответ, указывающий на успешность процедуры и содержащий ее выходные параметры. На рис. 15.2 показан обмен
Рис. 15.2. Взаимодействие в RPC
15.3 Программы и процедуры RPC
Основные концепции RPC достаточно просты:
■ Служба RPC реализуется одной или несколькими выполняющимися на сервере программами. Например, существуют отдельные программы управления доступом и блокировок файлов.
■ Каждая программа может выполнять несколько процедур. Идея состоит в том, что процедура должна реализовывать одну простую, четко ограниченную функцию. Например, существуют отдельные процедуры файлового доступа NFS для операций чтения, записи, переименования и удаления файлов.
■ Каждой программе присвоен числовой идентификатор.
■ Каждая процедура программы также имеет числовой идентификатор.
На момент написания книги выделением уникальных номеров для программ занималась компания Sun Microsystems (в будущем это должно перейти под юрисдикцию IANA). Диапазоны идентификаторов программ показаны в таблице 15.1. Числовой идентификатор присваивается процедурам программы разработчиком этой программы. Например, процедура чтения NFS — 6, а переименования NFS — 11.
Таблица 15.1 Присваивание номеров в RPC
| 0–1fffffff | Определяются компанией Sun (rpc@sun.com) |
| 20000000–3fffffff | Номера только для использования внутри сайта |
| 40000000–5fffffff | Для приложений, динамически генерирующих номера программ |
| 60000000–7fffffff | Зарезервировано |
| 80000000–9fffffff | Зарезервировано |
| a0000000–bfffffff | Зарезервировано |
| c0000000–dfffffff | Зарезервировано |
| e0000000–ffffffff | Зарезервировано |
Запрос клиента RPC идентифицирует запускаемую программу и процедуру по ее номеру. Например, чтобы прочитать файл, запрос RPC обратится к программе 100003 (NFS) и процедуре 6 (чтение). На рис. 15.3 показано клиентское приложение, обращающееся к удаленной процедуре программы 100003.
Опыт показывает, что через какое-то время программы меняются. Процедуры дорабатываются, и их становится все больше. По этой причине запрос RPC должен указывать версию программы. Очень часто на хосте сервера одновременно работает несколько версий одной программы RPC.
Рис. 15.3.
Удаленный запрос к процедуре (RPC) послан от клиента серверу в форматированном сообщении. RPC не заботится о том, какой транспортный протокол используется для пересылки сообщения. В мире TCP/IP RPC может работать поверх UDP или TCP, но можно использовать и другой транспорт.
Хотя обычно предполагается взаимодействие клиента с уникальным сервером, запросы RPC могут передаваться в многоадресных или широковещательных рассылках.
15.4 Типичная программа RPC
Наиболее известной программой RPC является NFS. Соответствующая команда mount (монтировать) позволяет клиенту подключить к своей локальной файловой системе удаленный каталог. Эта команда также является программой RPC. Существуют lock manager (диспетчер блокировки) и программа status, которые обеспечивают основу для изменения пользователем разделяемых файлов на сервере NFS.
Spray (распыление) — пример очень простой программы RPC. Клиент spray посылает серию сообщений к удаленной системе и получает ответ. Представленная ниже команда посылает 100 датаграмм хосту plum (эта программа позволяет получить статистику пересылки группы сообщений. — Прим. пер.):
Программа rusers выясняет, кто зарегистрирован на хостах из указанного списка или на всех хостах локальной сети. Клиент rusers отправляет запрос RPC через широковещательные рассылки локальной сети. Ответы содержат имена хостов и список пользователей, зарегистрированных на каждом из них.
15.5 Работа с дубликатами запросов RPC
Если служба основана на протоколе TCP, запросы и ответы будут доставляться надежно. TCP берет на себя обеспечение целостности доставляемых данных.
Если RPC базируется на UDP, то, в зависимости от требований конкретного приложения, клиент и сервер должны обеспечить собственный тайм-аут, повторную пересылку и стратегию выделения дублированных сообщений. Разработчик приложения может выбрать для клиента любую из следующих стратегий:
■ Если в пределах тайм-аута не будет получен ответ, послать сообщение об ошибке конечному пользователю, который и должен снова инициировать запрос к службе.
■ Если в пределах тайм-аута не будет получен ответ, отправить запрос еще раз. Повторять эту операцию до тех пор, пока не будет получен ответ или не будет достигнут максимальный предел повторной пересылки.