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

Начальным моментом для динамического связывания есть формальное определение (спецификация) серверу. Спецификация содержит имя файла-серверу, номер версии и список процедур-услуг, предоставленных данным сервером для клиентов (рисунок 3.5). Для каждой процедуры дается описание ее параметров с указанием того, есть ли данный параметр входным или исходным относительно серверу Некоторые параметры могут быть одновременно входными и исходными - например, некоторый массив, который ссылается клиентом на сервер, модифицируется там, а потом поворачивается обратно клиенту (операция copy/ restore).

Рис. 3.5. Спецификация серверу RPC

Формальная спецификация серверу используется в качестве исходных данных для программы-генератора стабов, что создает как клиентские, так и серверные стабы. Потом они помещаются в соответствующие библиотеки. Когда клиентская программа вызывает любую процедуру, определенную в спецификации серверу, который отвечает стаб-процедура связывается с двоичным кодом программы. Аналогично, когда компилируется сервер, с ним связываются серверные стабы.

При запуска сервера первейшим его действием является передача своего серверного интерфейса специальной программе, называемой binder'ом. Этот процесс, известный как процесс регистрации сервера, включает передачу сервером своего имени, номера версии, уникального идентификатора и описателя местонахождение сервера. Описатель системно независимый и может представлять собой IP, Ethernet, X.500 или еще какой-либо адрес. Кроме того, он может содержать и другую информацию, например, что относится к аутентификации.

Когда клиент вызывает одну из отдаленных процедур первый вместе, например, read, клиентский стаб видит, что он еще не подсоединен к серверу, и посылает сообщение binder- программе по просьбой об импорте интерфейса нужной версии нужного серверу. Если такой сервер существует, то binder передает описатель и уникальный идентификатор клиентскому стабу.

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

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

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

 

Возможно стоит прочитать: