Фертиков В.В. Распределенные вычисления: технология Microsoft RPC. Часть1

Подождите немного. Документ загружается.

ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ РФ

ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Распределенные вычисления:

технология Microsoft RPC

Учебное пособие по специальности 230201 (071900)

«Информационные системы и технологии»

ДС .09

Часть 1

ВОРОНЕЖ

2005

Утверждено Научно- методическим советом Воронежского университета

Протокол № 12 от 18.02.2005 г.

Составитель Фертиков В .В .

Пособие подготовлено на кафедре информационных систем факультета компь-

ютерных наук Воронежского государственного университета.

Рекомендуется для использования студентами 4 курса дневного отделения в ка-

честве учебных материалов на практических занятиях по курсу «Распределен-

ные системы вычислений».

Концепция удаленного вызова процедур

Распределенные вычисления имеют дело с понятиями более высокого

уровня , чем физические носители, каналы связи и методы передачи по ним со-

общений . Распределенная среда должна дать пользователям и приложениям

прозрачный доступ к данным , вычислениям и другим ресурсам в гетерогенных

системах , представляющих собой набор средств различных производителей .

Стратегические архитектуры каждого крупного системного производителя ба-

зируются сейчас на той или иной форме распределенной вычислительной сре-

ды (Distributed Computing Environment – DCE). Ключом к пониманию выгоды

такой архитектуры является прозрачность. Пользователи не должны тратить

свое время на попытки выяснить, где находится тот или иной ресурс, а разра-

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

положение в сети.

Хорошо известный механизм для реализации распределенных вычислений ,

вызов удаленных процедур (Remote Procedure Call – RPC), расширяет традици-

онную модель программирования – вызов процедуры – для использования в се-

ти. RPC может составлять основу распределенных вычислений . В каждом вы -

зове удаленной процедуры участвуют две стороны : активный клиент, который

отправляет запрос вызова процедуры на сервер , и сервер , который отправляет

клиенту ответ. Следует иметь в виду, что термины «клиент» и «сервер» в дан -

ном случае относятся к определенной транзакции. Конкретное программное

обеспечение (процесс или программа) могут работать как в роли клиента, так и

в роли сервера. Наибольшая эффективность использования RPC достигается в

тех приложениях, в которых существует интерактивная связь между удаленны -

ми компонентами с небольшим временем ответов и относительно малым коли-

чеством передаваемых данных. Такие приложения называются RPC-

ориентированными.

Характерными чертами вызова локальных процедур являются асиммет -

ричность (то есть одна из взаимодействующих сторон является инициатором )

и синхронность (то есть выполнение вызывающей процедуры приостанавлива-

ется с момента выдачи запроса и возобновляется только после возврата из вы -

зываемой процедуры ). Подобными свойствами обладает и удаленный вызов:

процесс клиента отправляет серверу сообщение, в которое включены парамет-

ры вызываемой процедуры и ожидает ответного сообщения с результатами ее

работы . При получении ответа результат считывается , и процесс продолжает

работу . Со стороны сервера процесс- обработчик вызовов находится в состоя-

нии ожидания и при поступлении сообщения считывает параметры процедуры ,

выполняет ее , отправляет ответ и становится в состояние ожидания следующе-

го вызова. Необходимо заметить, однако, что протокол RPC не накладывает ка-

ких- либо требований на дополнительные связи между процессами и не требует

синхронности выполняемых функций , т. е. вызовы могут быть асинхронными и

взаимно независимыми, так что клиент во время ожидания ответа может вы -

полнять другие процедуры. Сервер RPC может выделять для каждой функции

отдельный процесс или виртуальную машину , поэтому, не дожидаясь оконча-

ния работы предыдущих запросов, сразу же может принимать следующие.

Протокол RPC может использовать несколько различных транспортных

протоколов. В обязанности RPC-протокола входит только обеспечение стан -

дартов и интерпретация передачи сообщений . Достоверность и надежность пе-

редачи сообщений целиком обеспечивается транспортным уровнем . Однако

RPC может контролировать выбор и некоторые функции транспортного прото -

кола. RPC никогда не дублирует функции транспортных протоколов. Если, на-

пример , RPC работает поверх TCP, все заботы о надежности и достоверности

соединения RPC возлагает на TCP. Если протокол RPC установлен поверх UDP,

он может обеспечивать дополнительные собственные функции обеспечения га-

рантированной доставки сообщений .

Идея , положенная в основу RPC, состоит в том , чтобы сделать вызов уда-

ленной процедуры выглядящим по возможности так же, как и вызов локальной

процедуры . Другими словами – сделать RPC прозрачным: вызывающей проце-

дуре не требуется знать, что вызываемая процедура находится на другой маши-

не, и наоборот. Реализация удаленных вызовов существенно сложнее реализа-

ции вызовов локальных процедур. Начнем с того , что поскольку вызывающая и

вызываемая процедуры выполняются на разных машинах , то они имеют разные

адресные пространства, и это создает проблемы при передаче параметров и ре-

зультатов, особенно если машины не идентичны . Так как RPC не может рассчи-

тывать на разделяемую память, то это означает, что параметры RPC не должны

содержать указателей на ячейки нестековой памяти и что значения параметров

должны копироваться с одного компьютера на другой . Следующим отличием

RPC от локального вызова является то , что он обязательно использует нижеле-

жащую систему связи, однако это не должно быть явно видно ни в определении

процедур, ни в самих процедурах . Удаленность вносит дополнительные про-

блемы. Выполнение вызывающей программы и вызываемой локальной проце-

дуры в одной машине реализуется в рамках единого процесса. Но в реализации

RPC участвуют как минимум два процесса – по одному в каждой машине. В

случае аварийного завершения какого - либо из них могут возникнуть следую-

щие ситуации: при аварии вызывающей процедуры , удаленно вызванные про-

цедуры станут «осиротевшими» , а при аварийном завершении удаленных про-

цедур станут «обездоленными родителями» вызывающие процедуры , которые

будут безрезультатно ожидать ответа от удаленных процедур. Кроме того , су -

ществует ряд проблем , связанных с неоднородностью языков программирова-

ния и операционных сред : структуры данных и структуры вызова процедур,

поддерживаемые в каком -либо одном языке программирования, не поддержи-

ваются точно так же во всех других языках .

Технология RPC решает эти и некоторые другие проблемы, достигая про-

зрачности путем включения в процесс взаимодействия клиента и сервера спе-

циальных программных компонентов, стабов (stub - заглушка). Взаимодейст-

вие программных компонентов при выполнении удаленного вызова процедуры

иллюстрируется рис. 1. Когда вызываемая процедура действительно является

удаленной , в библиотеку помещается вместо локальной процедуры другая вер -

сия процедуры , называемая клиентским стабом . Задача заглушки – принять ар -

гументы , предназначаемые удаленной процедуре, преобразовать их в некий

стандартный формат и сформировать сетевой запрос. Упаковка аргументов и

создание сетевого запроса называется сборкой (marshalling).

После того , как сообщение готово к передаче, выполняется прерывание по

вызову ядра операционной системы. Когда ядро получает управление, оно пе-

реключает контексты , сохраняет регистры процессора и карту памяти (дескрип-

торы страниц), устанавливает новую карту памяти, которая будет использо-

ваться для работы в режиме ядра. Поскольку контексты ядра и пользователя

различаются , ядро должно точно скопировать сообщение в свое собственное

адресное пространство , так , чтобы иметь к нему доступ, запомнить адрес на-

значения (а, возможно, и другие поля заголовка), а также оно должно передать

его сетевому интерфейсу . На этом завершается работа на клиентской стороне.

Включается таймер передачи, и ядро может либо выполнять циклический опрос

наличия ответа, либо передать управление планировщику , который выберет ка-

кой -либо другой процесс на выполнение. В первом случае ускоряется выполне-

ние запроса, но отсутствует мультипрограммирование.

На стороне сервера поступающие биты помещаются принимающей аппа-

ратурой либо во встроенный буфер , либо в оперативную память. Когда вся ин-

формация будет получена, генерируется прерывание. Обработчик прерывания

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

передать. Если ни один из стабов не ожидает этот пакет, обработчик должен

либо поместить его в буфер , либо вообще отказаться от него . Если имеется

ожидающий стаб, то сообщение копируется ему. Наконец, выполняется пере-

ключение контекстов, в результате чего восстанавливаются регистры и карта

памяти, принимая те значения, которые они имели в момент, когда стаб сделал

системный вызов receive для перехода в режим ожидания приема сообщения .

Рис. 1. Взаимодействие программных компонентов

Клиент- машина

Сервер - машина

Стаб

клиента

Процесс-

клиент

Ядро клиента

Стаб

сервера

Процедура

Ядро сервера

сообщение- вызов

сообщение- результат

вызов

результат

вызов

результат

Теперь начинает работу серверный стаб. Он распаковывает параметры и

помещает их соответствующим образом в стек . Извлечение (unmarshalling) мо-

жет включать необходимые преобразования (например , изменения порядка

расположения байтов). Когда все готово , выполняется вызов настоящей проце-

дуры -сервера, которой адресован запрос клиента, с передачей ей полученных

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

клиенту . Для этого выполняются все описанные выше этапы , только в обратном

порядке: стаб сервера преобразует возвращенные процедурой значения, форми-

руя сетевое сообщение- отклик , который передается по сети системе, от которой

пришел запрос. Операционная система передает полученное сообщение стабу

клиента, который, после необходимого преобразования, передает значения (яв-

ляющиеся значениями, возвращенными удаленной процедурой ) клиенту , вос-

принимающему это как нормальный возврат из процедуры . Рис. 2 демонстри-

рует описанные этапы выполнения RPC-вызова.

Рис. 2. Этапы выполнения процедуры RPC

Итак , с точки зрения клиента, он производит вызов удаленной процедуры ,

как он это сделал бы для локальной . То же самое можно сказать и о сервере:

вызов процедуры происходит стандартным образом , некий объект (стаб серве-

ра) производит вызов локальной процедуры и получает возвращенные ею зна-

чения. Клиент воспринимает стаб как вызываемую процедуру -сервер , а сервер

принимает собственную заглушку за клиента.

Таким образом , стабы составляют ядро системы RPC, отвечая за все аспек -

ты формирования и передачи сообщений между клиентом и удаленным серве-

ром (процедурой ), хотя и клиент и сервер считают, что вызовы происходят ло-

кально. В этом -то и состоит основная концепция RPC – полностью спрятать

распределенный (сетевой ) характер взаимодействия в коде стабов. Преимуще-

ства такого подхода очевидны : и клиент и сервер являются независимыми от

сетевой реализации, оба они работают в рамках некой распределенной вирту -

альной машины , и вызовы процедур имеют стандартный интерфейс. В то же

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

робности протокола RPC или программировать обработку сообщений . Система

предполагает существование соответствующей среды разработки, которая зна-

чительно облегчает жизнь создателям прикладного программного обеспечения.

Одним из ключевых моментов в RPC является то , что разработка распределен-

ного приложения начинается с определения интерфейса – формального описа-

ния функций сервера, сделанного на специальном языке. На основании этого

интерфейса затем автоматически создаются стабы клиента и сервера. Единст-

венное, что необходимо сделать после этого , – написать фактический код про-

цедуры.

Реализация RPC фирмы Microsoft

Microsoft Remote Procedure Call (MS RPC) для языков программирования C

и C++ представляет совокупность трех моделей программирования распреде-

ленных вычислений : обычная модель разработки приложений на C путем напи-

сания процедур и библиотек ; модель, которая использует мощные компьютеры

в качестве сетевых серверов, выполняющих специфические задачи для своих

клиентов; и модель клиент- сервер , в которой клиент обычно управляет интер -

фейсом пользователя, в то время как сервер занимается выборкой , манипулиро-

ванием и хранением данных. Выделим основные их особенности.

Программная модель.

Язык C поддерживает процедурно-ориентированное программирование.

Все процедурно-ориентированные языки обеспечивают простые механизмы

определения и описания процедур. Например , ANSI стандарт прототипа функ -

ции C – конструкция , используемая для определения имени процедуры , типа

возвращаемого результата (если есть), а также числа, последовательности, и

типов параметров. Использование функционального прототипа – формальный

способ определить интерфейс между процедурами. Далее термин «процедура»

используется как синоним термина «подпрограмма» для обозначения любой

последовательности компьютерных команд , выполняющих функциональную

цель. Термин «функция» обозначает процедуру , которая возвращает значение.

Связанные процедуры часто группируются в библиотеках . Так , библиотека

может включать набор процедур, которые выполняют задачи в какой -либо об-

щей области, например , математические операции с плавающей запятой , фор-

матируемый ввод / вывод , сетевые функции. Библиотека процедур – следую-

щий уровень упаковки, облегчающий разработку прикладных программ. Биб-

лиотеки могут разделяться многими прикладными программами. Библиотеки,

разработанные на C, обычно сопровождаются файлами заголовков. Каждая

программа, использующая библиотеку , компилируется с файлами заголовков,

которые формально определяют интерфейс к процедурам библиотеки.

Инструментальные средства Microsoft RPC представляют общий подход ,

который позволяет библиотекам процедур, написанным на C, выполняться на

других компьютерах . Фактически, прикладная программа может компоноваться

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

пользователя об использовании RPC.

Модель клиент-сервер.

Архитектура клиент- сервер – эффективный и популярный проект распре-

деленных приложений . В модели приложение разделяется на две части: фрон-

тальный клиент, который представляет информацию пользователю , и оконеч-

ный сервер , сохраняющий и манипулирующий данными и вообще – произво -

дящий большую часть вычислительных задач для пользователя. В этой модели

сервер – обычно более мощный компьютер , чем клиент, и служит центральным

хранилищем данных для многих компьютеров клиентов, делая систему простой

в управлении. Типичными примерами приложений клиент-сервер являются

разделяемые базы данных, удаленные файловые серверы и удаленные серверы

печати.

Сетевые системы поддерживают разработку приложений клиент-сервер с

использованием средств межпроцессных взаимодействий (interprocess

communication – IPC), которые позволяют клиенту и серверу связываться и ко-

ординировать их работу . Например , клиент может использовать механизм IPC,

чтобы послать код операции и данные на сервер , запрашивая вызов специфиче-

ской процедуры . Сервер получает и декодирует запрос, затем вызывает соот-

ветствующую процедуру , выполняет все вычисления, необходимые для удовле-

творения запроса, затем возвращает результат пользователю . Приложения кли-

ент- сервер обычно разрабатываются с целью минимизации количества переда-

ваемых по сети данных. В дополнение ко всем возможным ошибкам , которые

могут происходить на одиночном компьютере, сеть имеет и собственные усло-

вия возникновения ошибок . Например , соединение может быть потеряно, сер -

вер может исчезнуть из сети, сетевая служба безопасности может отвергнуть

доступ к ресурсам системы, пользователи могут конкурировать при использо-

вании ресурсов. Итак , при написании приложения клиент- сервер необходимо

обеспечить уровень кода, который управлял бы сетевой связью с обработкой

все возможные условий возникновения ошибок . Преимущество использования

Microsoft RPC в том , что инструментальные средства RPC сами обеспечивают

этот уровень: RPC почти устраняет потребность писать специфический для се-

ти код . Инструментальные средства RPC управляет многими деталями в отно-

шении сетевых протоколов и связи, позволяя разработчику сосредоточиться на

деталях приложения.

Модель сервера-вычислителя.

RPC представляет шаг развития модели клиент- сервер , в которой под сер -

верами подразумеваются файловые серверы, серверы печати, или серверы свя -

зи, в зависимости от того , обеспечивают ли они совместное использование

файлов или соединены с принтерами или модемами. В дополнение к этим тра-

диционным ролям , сервер , использующий RPC, может играть роль вычисли-

тельной станции. В этой роли, сервер предоставляет собственную вычисли-

тельную мощность другим компьютерам сети, а клиент использует не только

файлы и принтеры , но также и центральные модули обработки других компью -

теров.

Компоненты Microsoft RPC

Реализация Microsoft RPC совместима со стандартом DCE консорциума

OSF (Open Software Foundation) с небольшими отличиями. Клиентские или сер -

верные приложения , написанные с использованием Microsoft RPC, могут экс-

плуатироваться совместно с любыми DCE RPC серверами или клиентами, чьи

библиотеки времени выполнения работают над поддерживаемым протоколом

(список поддержанных протоколов см . ниже).

Продукт Microsoft RPC включает следующие главные компоненты :

• компилятор MIDL;

• библиотеки времени выполнения и заголовочные файлы;

• модули транспортного интерфейса;

• провайдер сервиса имен;

• сервис подключения (Endpoint supply service).

Как сказано выше, в модели RPC предусматривается формальное опреде-

ление интерфейса к удаленным процедурам с использованием специального

языка. Это так называемый язык определения интерфейсов , или IDL (Interface

Definition Language). Реализация Microsoft этого языка называется MIDL. После

того , как интерфейс описан , необходимо обработать его компилятором MIDL.

Компилятор генерирует стабы (stub), которые транслируют локальные вызовы

процедуры в удаленные. Стабы являются заместителями функций и в свою

очередь производят вызовы функций библиотеки времени выполнения, выпол -

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

сеть становится почти полностью прозрачной для распределенного приложе-

ния . Клиентская программа как будто бы вызывает локальные процедуры ; ра-

бота по превращению их в удаленные вызовы выполняется автоматически. Весь

код , который транслирует данные, обращается к сети и возвращает результаты ,

генерируется компилятором MIDL и невидим для прикладной программы.

Особенности работы MS RPC

Как выяснено раньше, инструментальные средства RPC позволяют вызы-

вать процедуру , размещенную в удаленной серверной программе, как если бы

она размещалась локально . Клиент и сервер имеют свои собственные адресные

пространства; то есть каждый имеет собственный ресурс памяти, выделенный

для размещения данных, используемых процедурой . Клиентское приложение

вызывает локальную процедуру стаба вместо фактического кода, реализующего

процедуру . Стабы компилируются и компонуются с клиентской программой .

Вместо фактического кода, реализующего удаленную процедуру , код стаба

пользователя:

• выбирает требуемые параметры из адресного пространства клиента;

• транслирует параметры в стандартный сетевой формат представле-

ния данных (NDR – network data representation), что необходимо для их

передачи по сети;

• вызывает функции клиентской RPC-библиотеки времени выполнения,

чтобы послать запрос и параметры серверу .

Сервер выполняет следующие шаги , чтобы вызвать удаленную процедуру :

• функции серверной RPC-библиотеки времени выполнения принимают

запрос и вызывают процедуру серверного стаба;

• стаб сервера выбирает параметры из сетевого буфера и преобразует их

из сетевого формата передачи в формат , необходимый серверу ;

• стаб сервера вызывает фактическую серверную процедуру .

Удаленная процедура выполняется , возможно , генерируя выходные пара-

метры и возвращаемое значение. Когда удаленная процедура завершается , по-

добная вышеописанной последовательность шагов возвращает данные клиенту :

• удаленная процедура возвращает данные серверному стабу ;

• стаб сервера преобразует выходные параметры в формат , требуемый

для передачи по сети, и возвращает их функциям RPC-библиотеки вре-

мени выполнения;

• функции серверной RPC-библиотеки передают данные по сети на ком -

пьютер клиента.

Клиент завершает процесс, принимая данные из сети и возвращая их вы -

звавшей функции:

• клиентская RPC-библиотека получает возвращаемые удаленной

процедурой значения и возвращает их клиентскому стабу ;

• клиентский стаб преобразует данные из сетевого представления в фор-

мат , используемый компьютером клиента, записывает данные в память

клиента и возвращает результат вызвавшей клиентской программе;

• вызвавшая процедура продолжается, как после локального вызова.

Для Microsoft Windows и Microsoft Windows NT, библиотеки времени вы -

полнения состоят из двух частей : импортируемой библиотеки, компонуемой с

прикладной программой , и RPC-библиотеки времени выполнения, которая реа-

лизована как динамическая (DLL). Серверное приложение содержит вызовы

функций серверной библиотеки времени выполнения, которые регистрируют

интерфейс сервера и позволяют серверу принимать удаленные вызовы . Сервер -

ное приложение также содержит и сами специфические удаленные процедуры ,

предназначенные для вызова клиентскими приложениями.

Учебный пример распределенного приложения

Это введение в RPC представлено очень простой прикладной программой ,

концентрирующей внимание на различиях между автономными программами

на C и распределенными приложениями, использующими RPC. Этот пример ,

конечно, не является исчерпывающим показом возможностей RPC, богатых

средств языка определения интерфейсов Microsoft (MIDL). Приложение печа-

тает слова «Привет, мир» . Клиентский компьютер делает удаленный вызов