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

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

После завершения определения протокола RPC необходимо реализовать за­глушки — клиентскую и серверную. К счастью, заглушки, работающие по одно­му протоколу, для разных процедур различаются лишь интерфейсом с прило­жениями. Интерфейс состоит из набора процедур, которые могут быть вызваны клиентом, но реализуются на сервере. Доступ к интерфейсу осуществляется обычно из определенного языка программирования, одного из тех, на которых написан клиент или сервер (хотя, строго говоря, это не обязательно). Для упро­щения работы интерфейсы часто описываются с использованием языка опреде­ления интерфейсов (Interface Definition Language, IDL). Интерфейс, определен­ный на чем-то вроде IDL, компилируется затем в заглушки клиента и сервера, а также в соответствующие интерфейсы времени компиляции и времени выпол­нения.

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

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

2 .2.3. Расширенные модели rpc

Удаленные вызовы процедур стали фактическим стандартом для связи в распре­деленных системах. Популярность этой модели объясняется ее несомненной про­стотой. В этом пункте мы рассмотрим два расширения базовой модели RPC, соз­данные для разрешения некоторых ее недостатков.

Входы

Базовая модель RPC предполагает, что вызывающая и вызываемая системы мо­гут связываться друг с другом для обмена сообщениями по сети. В общем случае это предположение истинно. Однако рассмотрим вариант, когда клиент и сервер установлены на одной машине. В стандартном случае мы должны использовать средства локального межпроцессного взаимодействия (InterProcess Communication, IPC), которые базовая операционная система предоставляет процессам, запущен­ным на одной машине. Так, например, в UNIX соответствующие средства вклю­чают в себя совместно используемую память, каналы и очереди сообщений (де­тальное обсуждение IPC в UNIX-системах можно найти в [439]).

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

В качестве компромисса некоторые операционные системы предоставляют процессам, размещенным на одной машине, эквивалент RPC под названием вхо­дов (doors). Вход — это обобщенное имя процедур, существующих в адресном пространстве процессов сервера, которые могут вызываться процессами, разме­щенными на одной с сервером машине. Входы впервые появились в операцион­ной системе Spring [297] и были хорошо описаны в [193]. Сходный механизм, под названием упрощенный вызов RPC (lightweight RPC), описан в [49].

Вызов входов требует поддержки локальной операционной системы, как по­казано па рис. 2.11. Так, для того чтобы появилась возможность вызвать вход, процесс сервера должен зарегистрировать его. При регистрации входа возвраща­ется его идентификатор, который впоследствии можно будет использовать в ка­честве символического имени входа. Регистрация заканчивается вызовом door_ create. Доступ других процессов к зарегистрированному входу может осуществ­ляться просто по тому идентификатору, который мы получили при регистрации входа. Так, например, в Solaris каждый вход имеет файловое имя, которое можно получить через идентификатор простым вызовом fattach. Клиент вызывает вход через системный вызов door_call, в который идентификатор входа передается так же, как и любой другой обязательный параметр. Затем операционная систе­ма производит вызов того процесса, который зарегистрировал вход. Результатом этого вызова будет вызов входа сервера. Результаты вызова входа будут возвра­щены в процесс клиента через системный вызов door_return.

Главное преимущество входов состоит в том, что они позволяют использо­вать для связи в распределенных системах единый механизм — вызовы процедур.