Читаем без скачивания TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) - Сидни Фейт

Стандарт внешнего представления данных (eXternal Data Representation — XDR) является важной частью архитектуры RPC. XDR включает язык описания типов данных и методы их кодирования в стандартный формат. Это позволяет производить обмен данными между компьютерами различных типов, например между хостами Unix, PC, Macintosh, системами VAX VMS компании Digital Equipment Corporation и большими ЭВМ компании IBM.

15.1.3 RPC как стандарт Интернета

Компания Sun Microsystems опубликовала RFC с описанием RPC в 1988 г., a NFS — в 1989 г. Однако Sun контролировала эти протоколы вплоть до 1995 г., пока не появились новые версии. С этого момента ответственность за RFC архитектуры ONC перешла к комитету IETF, а сама архитектура была принята в качестве стандарта для процессов Интернета. Sun взаимодействовала с консорциумом X/Open при разработке новой версии NFS.

15.1.4 Реализации NFS и RPC

NFS и RPC были реализованы многими разработчиками систем Unix, а также перенесены во многие лицензированные операционные системы. Например, IBM VM, IBM MVS и DEC VAX VMS могут работать как файловые серверы NFS.

Некоторые разработчики объединили программное обеспечение клиента и сервера NFS с собственными продуктами TCP/IP, в то время как другие предоставляли NFS за дополнительную плату. Во многих продуктах NFS содержится программная библиотека для RPC.

Множество продуктов TCP/IP для Windows обеспечивает работу системы Windows в качестве клиента NFS, а некоторые реализации — и как серверы NFS. Последние версии NetWare компании Novell поддерживают NFS вместе с собственными службами файлов и печати. Любой клиент может обращаться к серверу по любому из этих протоколов. В частности, поддерживаются клиенты DOS, Macintosh и Unix.

15.2 Модель RPC

Приложение клиент/сервер для архитектуры ONC функционирует поверх RPC. Работа RPC моделируется обычными вызовами подпрограмм. Например, в языке программирования С вызов обычной подпрограммы в общем случае имеет форму:

код_возврата = имя_процедуры (входные_параметры, выходные_параметры)

Перед активизацией процедуры входные данные сохраняются как входные_параметры. Если процедура завершается успешно, полученные результаты сохраняются в выходных параметрах. По завершении код возврата указывает на успешность работы процедуры.

RPC работает аналогичным образом. Локальная система посылает запрос вызова на удаленный сервер. Запрос идентифицирует процедуру и получает входные параметры. Удаленный сервер выполняет процедуру. По завершении работы удаленный сервер формирует ответ, указывающий на успешность процедуры и содержащий ее выходные параметры. На рис. 15.2 показан обмен запросом и ответом. Протокол RPC определяет механизм данного способа работы.

Рис. 15.2. Взаимодействие в RPC

15.3 Программы и процедуры RPC

Основные концепции RPC достаточно просты:

■ Служба RPC реализуется одной или несколькими выполняющимися на сервере программами. Например, существуют отдельные программы управления доступом и блокировок файлов.

■ Каждая программа может выполнять несколько процедур. Идея состоит в том, что процедура должна реализовывать одну простую, четко ограниченную функцию. Например, существуют отдельные процедуры файлового доступа NFS для операций чтения, записи, переименования и удаления файлов.

■ Каждой программе присвоен числовой идентификатор.

■ Каждая процедура программы также имеет числовой идентификатор.

На момент написания книги выделением уникальных номеров для программ занималась компания Sun Microsystems (в будущем это должно перейти под юрисдикцию IANA). Диапазоны идентификаторов программ показаны в таблице 15.1. Числовой идентификатор присваивается процедурам программы разработчиком этой программы. Например, процедура чтения NFS — 6, а переименования NFS — 11.

Таблица 15.1 Присваивание номеров в RPC

0–1fffffff Определяются компанией Sun ([email protected]) 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 (эта программа позволяет получить статистику пересылки группы сообщений. — Прим. пер.):

> spray -с 100 plum

sending 100 packets of lnth 86 to plum …

in 10.1 seconds elapsed time,

29 packets (29.00%) dropped by plum

Sent: 9 packets/sec, 851 bytes/sec

Rcvd: 7 packets/sec, 604 bytes/sec

Программа rusers выясняет, кто зарегистрирован на хостах из указанного списка или на всех хостах локальной сети. Клиент rusers отправляет запрос RPC через широковещательные рассылки локальной сети. Ответы содержат имена хостов и список пользователей, зарегистрированных на каждом из них.

> rusers

Zonker.num.cs.yale.edu leonard jones harris

Mark.num.cs.yale.edu   davis   sherman

Duke.num.cs.yale.edu   burry   victor

. . .

15.5 Работа с дубликатами запросов RPC

Если служба основана на протоколе TCP, запросы и ответы будут доставляться надежно. TCP берет на себя обеспечение целостности доставляемых данных.

Если RPC базируется на UDP, то, в зависимости от требований конкретного приложения, клиент и сервер должны обеспечить собственный тайм-аут, повторную пересылку и стратегию выделения дублированных сообщений. Разработчик приложения может выбрать для клиента любую из следующих стратегий:

■ Если в пределах тайм-аута не будет получен ответ, послать сообщение об ошибке конечному пользователю, который и должен снова инициировать запрос к службе.

■ Если в пределах тайм-аута не будет получен ответ, отправить запрос еще раз. Повторять эту операцию до тех пор, пока не будет получен ответ или не будет достигнут максимальный предел повторной пересылки.

Если клиент повторно посылает запрос, разработчик должен реализовать на сервере стратегию обработки дубликатов сообщений. Сервер может:

■ Не фиксировать ранее выполненные операции. При поступлении запроса выполнить процедуру, даже если это был дубликат запроса. Отметим, что для некоторых процедур (например, чтение набора байт из файла) в этом нет ничего страшного. Конечно, клиент может и дальше получать двойные ответы, но может и блокировать их, отслеживая ранее выполненные транзакции.