Связывание клиента с сервером

Рассмотрим вопрос о том, как клиент узнает место расположения сервера, кото­рому необходимо послать сообщение-вызов. Процедура, устанавливающая соот­ветствие между клиентом и сервером RPC, носит название связывание (binding). Методы связывания, применяемые в различных реализациях RPC, отличаются:

□ способом задания сервера, с которым хотел бы быть связанным клиент;

□ способом обнаружения сетевого адреса (места расположения) требуемого сер­
вера процессом связывания;

□ стадией, на которой происходит связывание.

Метод связывания тесно связан с принятым методом именования сервера. В наи­более простом случае имя или адрес сервера RPC задается в явной форме, в ка­честве аргумента клиентского стаба или программы-сервера, реализующей ин­терфейс определенного типа. Например, можно использовать в качестве такого аргумента IP-адрес компьютера, на котором работает некоторый RPC-сервер, и номер TCP/UDP порта, через который он принимает сообщения-вызовы своих процедур. Основной недостаток такого подхода — отсутствие гибкости и про­зрачности. При перемещении сервера или при существовании нескольких серве­ров клиентская программа не может автоматически выбрать новый сервер или тот сервер, который в данный момент наименее загружен. Тем не менее во мно­гих случаях такой способ вполне приемлем и ввиду своей простоты часто ис­пользуется на практике. Необходимый сервер часто выбирает пользователь, на­пример путем просмотра списка или графического представления имеющихся в сети разделяемых файловых систем (набор этих файловых систем может быть собран операционной системой клиентского компьютера за счет прослушивания широковещательных объявлений, которые периодически делают серверы). Кро­ме того, пользователь может задать имя требуемого сервера на основании зара­нее известной ему информации об адресе или имени сервера.

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

Динамическое связывание требует изменения способа именования сервера. Наи­более гибким является использование для этой цели имени RPC-интерфейса, со­стоящего из двух частей:

□ типа интерфейса;

□ экземпляра интерфейса.

Тип интерфейса определяет все характеристики интерфейса, кроме его место­расположения. Это те же характеристики, который имеются в описании для IDL-компилятора, например файловая служба определенной версии, включающая процедуры open, close, read, write, и т. п. Часть, описывающая экземпляр интер­фейса, должна точно задавать сетевой адрес сервера, который поддерживает дан­ный интерфейс. Если клиенту безразлично, какой сервер его будет обслуживать, то вторая часть имени интерфейса опускается.

Динамическое связывание иногда называют импортом/экспортом интерфейса: клиент импортирует интерфейс, а сервер его экспортирует.

В том случае, когда для клиента важен только тип интерфейса, процесс обнару­жения требуемого сервера в сети с экземпляром интерфейса определенного типа может быть построен двумя способами:

□ с использованием широковещания;

□ с использованием централизованного агента связывания.

Эти два способа характерны для поиска сетевого ресурса любого типа по его име­ни, они уже рассматривались в общем виде в подразделе «Способы адресации» - раздела «Механизм передачи сообщений в распределенных системах»-. Первый способ основан на широковещательном распространении по сети серверами RPC имени своего интерфейса, включая и адрес экземпляра. Применение этого спосо­ба позволяет автоматически балансировать нагрузку на несколько серверов, под­держивающий один и тот же интерфейс, — клиент просто выбирает первое из подходящих ему объявлений.

Схема с централизованным агентом связывания предполагает наличие в сети сер­вера имен, который связывает тип интерфейса с адресом сервера, поддерживаю­щего такой интерфейс. Для реализации этой схемы каждый сервер RPC должен предварительно зарегистрировать тип своего интерфейса и сетевой адрес у аген­та связывания, работающего на сервере имен. Сетевой адрес агента связывания (в формате, принятом в данной сети) должен быть известным адресом как для серверов RPC, так и для клиентов. Если сервер по каким-то причинам не может больше поддерживать определенный RPC-интерфейс, то он должен обратиться к агенту и отменить свою регистрацию. Агент связывания на основании запросов регистрации ведет таблицу текущего наличия в сети серверов и поддерживаемых ими RPC-интерфейсов.

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

Агент связывания может работать в составе общей централизованной справоч­ной службы сети, такой как NDS, X.500 или LDAP (справочные службы более подробно рассматриваются в следующей главе).

Описанный метод, заключающийся в импорте/экспорте интерфейсов, обладает высокой гибкостью. Например, может быть несколько серверов, поддерживаю­щих один и тот же интерфейс, и клиенты распределяются по серверам случай­ным образом. В рамках этого метода становится возможным периодический опрос серверов, анализ их работоспособности и, в случае отказа, автоматическое отключение, что повышает общую отказоустойчивость системы. Этот метод мо­жет также поддерживать аутентификацию клиента. Например, сервер может опре­делить, что доступ к нему разрешается только клиентам из определенного списка.

Однако у динамического связывания имеются недостатки, например дополни­тельные накладные расходы (временные затраты) на экспорт и импорт интер­фейсов. Величина этих затрат может быть значительна, так как многие клиентские процессы существуют короткое время, а при каждом старте процесса процедура импорта интерфейса должна выполняться заново. Кроме того, в больших рас­пределенных системах может стать узким местом агент связывания, и тогда необходимо использовать распределенную систему агентов, что можно сделать стандартным способом, используя распределенную справочную службу (таким свойством обладают службы NDS, X.500 и LDAP).

Необходимо отметить, что и в тех случаях, когда используется статическое свя­зывание, такая часть адреса, как порт сервера интерфейса (то есть идентифи­катор процесса, обслуживающего данный интерфейс), определяется клиентом динамически. Эту процедуру поддерживает специальный модуль RPC Runtime, называемый в ОС UNIX модулем отображения портов (portmapper), а в ОС се­мейства Windows — локатором RPC (RPC Locator). Этот модуль работает на каждом сетевом узле, поддерживающем механизм RPC, и доступен по хорошо известному порту TCP/UDP. Каждый сервер RPC, обслуживающий определен­ный интерфейс, при старте обращается к такому модулю с запросом о выделении ему для работы номера порта из динамически распределяемой области (то есть с номером, большим 1023). Модуль отображения портов выделяет серверу некото­рый свободный номер порта и запоминает это отображение в своей таблице, свя­зывая порт с типом интерфейса, поддерживаемым сервером. Клиент RPC, выяс­нив каким-либо образом сетевой адрес узла, на котором имеется сервер RPC с нужным интерфейсом, предварительно соединяется с модулем отображения портов по хорошо известному порту и запрашивает номер порта искомого серве­ра. Получив ответ, клиент использует данный номер для отправки сообщений-вызовов удаленных процедур. Механизм очень похож на механизм, лежащий в основе работы агента связывания, но только область его действия ограничивает­ся портом одного компьютера.