su13@pochta.ru

| Первый | Второй | Третий | Четвёртый | Пятый | Шестой | Седьмой |


//

Процедура удаленного вызова (Remote Procedure Call)

Очень важный механизм для приложений "клиент-сервер" обеспечивается RPC (Remote Procedure Call). RPC был разработан Sun Micrsystems, и эта система представляет собой набор инструментальных средств и библиотечных функций. В частности на RPC работают NIS (Network Information System) и NFS (Network File System).

Сервер RPC состоит из системы таких процедур, что клиент может обратится, посылая RPC-запрос к серверу вместе с параметрами процедуры. Сервер вызовет обозначенную процедуру и вернет значение возврата процедуры, если оно есть. Чтобы быть машинно-независимыми, все данные, которыми обмениваются клиент и сервер, преобразуются к так называемому внешнему представлению данных (External Data Representation, XDR). RPC связан с сокетами UDP и TCP для передачи данных в формате XDR. Sun объявила RPC как public domain, и его описание доступно в серии документов RFC.

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

Сетевая связь между серверами и клиентами RPC немного особая. RPC-сервер предлагает одну или более системных процедур, каждое множество таких процедур называется программой (program) и однозначно идентифицировано номером программы (program number). Список имен сервисов обычно хранится в /etc/rpc, пример которого приведен ниже.

Пример 12-4. Образец файла /etc/rpc

#
# /etc/rpc - miscellaneous RPC-based services
#
portmapper      100000  portmap sunrpc
rstatd          100001  rstat rstat_svc rup perfmeter
rusersd         100002  rusers
nfs             100003  nfsprog
ypserv          100004  ypprog
mountd          100005  mount showmount
ypbind          100007
walld           100008  rwall shutdown
yppasswdd       100009  yppasswd
bootparam       100026
ypupdated       100028  ypupdate

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

Конечно, клиентские программы должны иметь способ выяснить, который порт соответсвует номеру программы. Использование для этого файла конфигурации было бы слишком негибким; с тех пор, как RPC-приложения не используют зарезервированные порты, нет никакой гарантии, что порт не занят каким-то приложением и доступен нам. Следовательно, RPC-приложения выбирают любой порт, который они могут получить, и регистрируют это с помощью portmapper daemon. Клиент, который хочет войти в контакт с сервисом с данным номером программы, сначала сделает запрос portmapper для выяснения номера порта нужного сервиса.

Этот метод имеет тот недостаток, что вводит единственную точку отказа, очень похожую на inetd daemon. Однако, этот случай немного хуже, потому что когда portmapper валится, вся информация RPC о портах теряется. Это обычно значит, что Вы должны перезапустить все RPC-серверы вручную или перезагрузить машину.

В Linux portmapper называется /sbin/portmap или /usr/sbin/rpc.portmap. Кроме того, что он должен быть запущен из скрипта запуска сети, рortmapper не требует никакой работы по конфигурации.

GNU OCXE GNU LINUX
Сайт управляется системой uCoz