TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
Отметим интересный момент: для определения состояния
Команда rpcinfo -b выполняет широковещательную рассылку в сети, запрашивая все работающие серверы о выполняемых ими программах и версиях этих программ. В приведенном ниже примере запрашиваются сведения о версии 1 программы spray под номером 100012.
Каждая программа RPC имеет пустую процедуру с номером 0, возвращающую только ответ "Я активна". Нижеприведенная команда rpcinfo -u посылает сообщение пустой процедуре программы spray хоста bulldog.cs.yale.edu:
15.7 Программа rpcbind
В последних версиях RPC программа portmapper заменена на rpcbind. Исходная программа portmapper связывалась с UDP или TCP. Rpcbind независима от используемого транспортного протокола. Эта программа возвращает строку ASCII, содержащую адресную информацию, которая не зависит от используемого транспорта и называется форматом универсального адреса (universal address format).
15.7.1 Назначение rpcbind
Программа rpcbind основана на тех же принципах, что и portmapper. При инициализации программы RPC ей выделяется один или несколько динамически назначенных адресов для транспорта. Программа регистрирует полученные адреса в rpcbind, через которую они становятся известными клиентам.
Запрос клиента содержит номер программы и номер версии. Но в ответе rpcbind указывается универсальный адрес, который может предоставлять специальные сведения для NetWare SPX/IPX, SNA, DECnet или AppleTalk, а не для TCP или UDP. Тип предоставленного в ответе транспортного адреса зависит от используемого для запроса транспортного протокола.
Как и к portmapper, к rpcbind обращаются по общеизвестному порту 111 через UDP или TCP. Для других коммуникационных протоколов должен использоваться другой, заранее определенный локальный доступ.
Подобно portmapper, rpcbind поддерживает службу широковещательных рассылок RPC. Рассылки направляются на общеизвестную точку доступа к транспорту, определенную для службы rpcbind, например порт 111 для UDP или TCP. Каждая программа rpcbind, которая отслеживает широковещательные рассылки, может от имени клиента вызвать нужную ей локальную сервисную программу, получить ответ и переслать его клиенту. Версия 4 протокола RPC позволяет клиентам получать через rpcbind такой же вид косвенного обслуживания при многоадресной рассылке, как и при широковещательной.
15.7.2 Процедуры rpcbind
Процедуры программы rpcbind версии 4 представлены в таблице 15.3.
Таблица 15.3 Процедуры rpcbind
| Процедура | Описание |
|---|---|
| RPCBPROC_SET | Используется службой регистрации программ через локальную RPCBIND. |
| RPCBPROC_UNSET | Используется для отмены регистрации локальной программы. |
| RPCBPROC_GETADDR | Возвращает клиенту универсальный адрес программы. |
| RPCBPROC_GETVERSADDR | В запрос включается нужный номер версии программы. |
| RPCBPROC_GETADDRLIST | Выводит список адресов программы. Клиент может выбрать из нескольких доступных транспортных протоколов. |
| RPCBPROC_DUMP | Список всех элементов базы данных RPCBIND (например, предоставление сведений для вывода командой rpcinfo). |
| RPCBPROC_BCAST | Поддержка широковещательного запроса — RPCBIND пересылает запрос локальной программе. |
| RPCBPROC_INDIRECT | Поддержка косвенных запросов, которые являются многоадресными — RPCBIND пересылает их локальной программе и возвращает назад результат или сообщение об ошибке. |
| RPCBPROC_GETTIME | Возвращает местное время сервера, отсчитанное в секундах от полночи первого дня января 1970 г. |
| BPCBPBOC_UADDR2TADDR | Преобразование универсальных адресов в адреса, специфичные для данного транспорта. |
| RPCBPROC_TADDR2UADDR | Преобразование специфичных для транспорта адресов в универсальные адреса. |
| RPCBPROC_GETSTAT | Предоставление статистики о количестве и типах полученных запросов. |
15.8 Сообщения RPC
Клиент RPC посылает запросы серверу и получает ответы на них в специальных сообщениях. Что должны содержать эти сообщения, чтобы клиент и сервер поняли друг друга?
Необходим идентификатор транзакции, определяющий соответствие между запросом и ответом. Запрос клиента должен указывать программу и процедуру, которую он хочет запустить. Клиенту необходим некоторый способ идентифицировать себя через мандат (credentials), доказывающий право использования службы. Наконец, запрос клиента должен содержать входные параметры. Например, запрос чтения NFS должен идентифицировать файл и количество читаемых байтов.
В дополнение к сообщению о результатах успешных запросов серверу необходим способ сообщения клиенту об отмене запроса и причинах такой отмены. Запрос может быть отклонен при несоответствии версий программы или ошибке при аутентификации клиента. Сервер должен сообщить об ошибках в параметрах или событиях, например: "Не могу найти файл".
На рис. 15.5 показано взаимодействие клиента с программой сервера. Клиент посылает запрос. Когда работа затребованной процедуры завершается, серверная программа возвращает ответ. Как видно из рис. 15.5, запрос включает:
■ Идентификатор транзакции
■ Текущий номер версии RPC
■ Номер программы
■ Версию программы
■ Номер процедуры
■ Мандат аутентификации
■ Проверочные сведения (verifier) аутентификации
■ Входные параметры
Рис. 15.5. Сообщения RPC
Если процедура выполнена успешно, ответ содержит результаты. Если при выполнении выявлены проблемы, ответ будет содержать информацию об ошибках.
15.9 Аутентификация в RPC
Некоторые службы не нуждаются в защите. Для вывода времени дня на сервере служба RPC может быть оставлена открытой для общего доступа. Однако клиент, обращающийся к личным данным, должен обеспечить некоторую опознавательную информацию (проходить аутентификацию). В некоторых случаях важно, чтобы сервер также подтверждал свою подлинность. Не следует посылать номер своей кредитной карточки через систему интерактивных заказов, если не будет гарантии в подлинности сервера. Таким образом, в некоторых случаях аутентификационные данные должен предоставлять как клиент, так и сервер (они будут как в запросах, так и в ответах).