Очень важный механизм для приложений "клиент-сервер" обеспечивается 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 не требует никакой работы по конфигурации.
| Назад | Глобальное оглавление | Вперед |
| Файлы services и protocols | Локальное оглавление | Настройка удаленного выполнения |
