Дистанционное управление
Очень общий механизм для клиент-сервера приложения обеспечивается RPC, пакетом дистанционного управления. RPC был разработан Sun Micrsystems, и эта система - набор инструментальных средств и библиотечных функций. Важные приложения, сформированны на вершине RPC - NFS, Network Filesystem, и NIS, Network Information System, обе из которых будут представлены в следующих главах.
RPC сервер состоит из системы процедур того, что клиент может обратится, посылая RPC запрос к серверу, наряду с параметрами процедуры. Сервер вызовет обозначенную процедуру по защите клиента, вручая обратно возвращаемое значение, если имеется любое. Чтобы быть машинно-независимыми, зсе жанные, обмененные между клиентом и сервером преобразованны к так называемому Внешнему Представлению Данных (XDR) отправителю, и преобразованны обратно к машинно - локальному
Иногда, уточнения к RPC приложению вводят несовместимые изменения в процедуре call interface. Конечно, при простом изменение сервер разрушил бы все приложение, которые все еще ожидают original behavior. Следовательно, RPC программы имеют номера версии, приписываемые к ним, обычно начинающийся с 1, и с каждой новой версией RPC свяжит с помощью интерфейса этот счетчик. Часто, сервер может предлагать несколько версий одновременно; клиентура затем указывает номером версии версии они хотят использовать.
Сетевая связь между RPC серверами и клиентурой - особая. RPC сервер предлагает один или более системных процедур; каждое множество называется программой, и однозначно идентифицировано номером программы. Имена обслуживания отбора списка существуют для того, чтобы запрограммировать числа обычно сохраняемые в /etc/rpc, выборка которого воспроизведена ниже ра рисунке 10.4
В TCP/IP сетях, перед авторами RPC стояла задача программирования чисел к обобщенным сетевым услугам. Они выбрали - иметь каждый сервер, обеспечивающий, и TCP и UDP порт для каждой программы и каждой версии. Вообще, RPC приложения используют UDP посылку данных, и возвращаются обратно к TCP тогда, когда данные, которые будут переданы не впишутся в единственную UDP датаграмму.
Конечно, клиентские программы должны иметь способ выяснить который из них порт отображения номера программы. Использование файла конфигурации для этого, был бы слишком негибки; с тех пор RPC приложения не используют зарезервированные порты, не имеется никакой гарантии, что порт первоначально подразумевал использоваться наше приложепие "баз данных. Следовательно, RPC приложения выбирают любой порт который, они могут получить, и зарегистрировать это с так называемым por действия - как обслуживание broker для всех RPC серверов, выполняющиеся на машине: клиент, который хочет войти в контакт с обслуживанием с данным номером программы сначала сделает запрос portmapper на числа порта обслуживание, которые могут быть достигнуты.
Этот метод имеет частичный недостаток, что это вводит единственную точку отказа, очень похожую на inetd daemon. Однако, этот случай немного хуже, потому что когда portmapper умирает, вся RPC информация порта теряется; это обычно значит, что Вы должны перезапустить все RPC серверы вручную, или перезагрузить целую машину.
На Linux, portmapper называется rpc.portmap и постоянно находится в /usr/sbin. Кроме уверения того, что это начато из rc.inet2, рortmapper не требует любой работы по конфигурации.
