Дистанционное управление

Очень общий механизм  для  клиент-сервера  приложения  обеспечивается   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, выборка   которого  воспроизведена  ниже.

В 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  не требует любой работы по конфигурации.