104 Глава 2. Связь

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

Асинхронный вызов RPC

В стандартном варианте вызова клиентом удаленной процедуры его работа при­останавливается до получения ответа. Когда ответ не нужен, этот жесткий алго­ритм «запрос-ответ» не является необходимым, приводя только к блокированию клиента с невозможностью производить работу до получения ответа от удален­ной процедуры. Примеры действий, при которых обычно нет необходимости в ожидании ответа: перечисление денег с одного банковского счета на другой, до­бавление записей в базу данных, запуск удаленной службы, пакетная обработка и множество других.

Для обработки подобных случаев системы RPC могут предоставлять средства для так называемого асинхронного вызова RPC (asynchronous RPC). При помощи этих средств клиент получает возможность продолжить свою работу сразу после выполнения запроса RPC. При асинхронном вызове RPC сервер немедленно по приходу запроса отсылает клиенту ответ, после чего вызывает запрошенную процедуру. Ответ служит подтверждением того, что сервер приступил к обработ­ке RPC. Клиент продолжает работу, снимая блокировку, сразу после получения

2.2. Удаленный вызов процедур 105

о т сервера этого подтверждения. На рис. 2.12, а приведен стандартный алгоритм взаимодействия «запрос-ответ», а на рис. 2.12, б — алгоритм взаимодействия кли­ента и сервера в случае асинхронного вызова RPC.

Асинхронные вызовы RPC также могут быть полезны в тех случаях, когда ответ будет послан, но клиент не готов просто ждать его, ничего не делая. На­пример, клиент может пожелать заранее выбрать сетевые адреса из набора хос­тов, с которыми вскоре будет связываться. В то время, пока служба именования соберет эти адреса, клиент может заняться другими вещами. В подобных случа­ях имеет смысл организовать сообщение между клиентом и сервером через два асинхронных вызова RPC, как это показано на рис. 2.13. Сначала клиент вызы­вает сервер, чтобы передать ему список имен хостов, который следует подгото­вить, и продолжает свою работу, когда сервер подтверждает получение этого списка. Второй вызов делает сервер, который вызывает клиента, чтобы передать ему найденные адреса. Комбинация из двух асинхронных вызовов RPC иногда называется также отложенным синхронным вызовом RPC (deferred synchronous RPC).

106 Глава 2. Связь

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

2.2.4. Пример — dce rpc

Механизм удаленных вызовов процедур был тщательно адаптирован для исполь­зования в качестве основы систем промежуточного уровня и вообще распреде­ленных систем. В этом пункте мы рассмотрим одну из специальных систем RPC: среду распределенных вычислений {Distributed Computing Environment, DCE), раз­работанную организацией OSF (Open Software Foundation), которая сейчас пе­реименована в Open Group. Система DCE RPC не настолько популярна, как некоторые другие системы RPC, например Sun RPC. Однако DCE RPC — пре­красный представитель систем RPC. Спецификация DCE RPC адаптирована к системе распределенных вычислений на базе решений Microsoft. Кроме того, как мы увидим в следующем пункте, DCE RPC вдобавок иллюстрирует отноше­ния между системами RPC и распределенными объектами. Мы начнем с крат­кого введения в DCE, за которым последует обсуждение принципов работы DCE RPC.

Знакомство с DCE

DCE — настоящая система промежуточного уровня, разработанная, чтобы абст­рагировать существующие (сетевые) операционные системы от распределенных приложений. Изначально она была разработана под UNIX, однако в настоящее время существуют версии DCE для всех распространенных операционных сис­тем, включая VMS и Windows NT, а также операционных систем настольных компьютеров. Идея состоит в том, что покупатель может взять набор компью­теров, поставить программное обеспечение DCE и начать запускать распределен­ные приложения, и все это без каких-либо неполадок в работе существующих (нераспределенных) приложений. Хотя большая часть пакета DCE работает в пространстве пользователя, в некоторых конфигурациях часть (отвечающая за распределенную файловую систему) может быть добавлена и к ядру. Сама по себе организация Open Group только продает исходные тексты, а поставщики встраивают их в свои системы.

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