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

Лекция №23

Тема. Виклик видалених процедур. Концепція видаленого виклику процедур. Генерація стабів.

Формат повідомлень RPC. Зв'язування клієнта з сервером

Цель. Объяснить вызов удаленных процедур, генерацию стабов, связь клиента с сервером.

1. Учебная.Рассказать файловых операциях открытия, закрытия файла, блокирования файла.

2. Развивающая.Развивать логическое мышление и естественное - научное мировоззрение.

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

Межпредметные связи:

· Обеспечивающие: информатика, математика, вычислительная техника и МП, системы программирования.

· Обеспечиваемые:Стажерская практика

Методическое обеспечение и оборудование:

1. Методическая разработка к занятию.

2. Учебный план.

3. Учебная программа

4. Рабочая программа.

5. Инструктаж по технике безопасности.

Технические средства обучения: персональный компьютер.

Обеспечение рабочих мест:

· Рабочие тетради

Ход лекции.

Организационный момент.

Анализ и проверка домашней работы

3. Ответьте на вопросы:

1. Поясните принцип адресации, когда одним из вариантов адресации является использование аппаратных адресов сете­вых адаптеров.

2. Почему номера портов яв­ляются на сегодня наиболее популярными адресами служб в системах обмена сообщениями сетевых ОС?

3. Какой недостаток имеет схема типа «машина-процесс» или - «машина-служба»?

4. Поясните для чего работает служба оперативного отображения символьных имен на числовые идентификаторы?

5. Какие схемы применяются для замены символьных адресов на числовые?

6. Что дает использование символьных имен вместо числовых? Недостаток метода.

7. Что подразумевает надежная передача сообщений?

8. Для каких целей могут поддерживаться надежные и ненадежные примитивы?

9. В каком случае используется протокол ТСР, а в каком UDP?

Вызов удаленных процедур.

Еще одним удобным механизмом, облегчающим взаимодействие операционных систем и приложений по сети, является механизм вызова удаленных процедур (Remote Procedure Call, RPC). Этот механизм представляет собой надстройку над системой обмена сообщениями ОС, поэтому в ряде случаев он позволяет более удобно и прозрачно организовать взаимодействие программ по сети, однако его полезность не универсальна.

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

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

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

□ асимметричность — одна из взаимодействующих сторон является инициато­ром взаимодействия;

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

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

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

□ при аварии вызывающей процедуры удаленно вызванные процедуры стано­вятся «осиротевшими»;

□ при аварийном завершении удаленных процедур становятся «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожи­дать ответа от удаленных процедур.

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

Рассмотрим, каким образом технология RPC, лежащая в основе многих распре­деленных операционных систем, решает эти проблемы.

Чтобы осуществить вызов, вызывающая процедура помещает заданные пара­метры в стек в обратном порядке и передает управление вызываемой процедуре my_write. Эта пользовательская процедура после некоторых манипуляций с дан­ными символьного массива buf выполняет системный вызов write для записи дан­ных в файл, передавая ему параметры тем же способом, то есть помещая их в стек (при реализации системного вызова они копируются в стек системы, а при возврате из него результат помещается в пользовательский стек). После того как процедура my_write выполнена, она помещает возвращаемое значение m в регистр, перемещает адрес возврата и возвращает управление вызывающей процедуре, кото­рая выбирает параметры из стека, возвращая его в исходное состояние.Заметим, что в языке С параметры могут вызываться по ссылке (by name), представляю­щей собой адрес глобальной области памяти, в которой хранится параметр, или по значению (by value), в этом случае параметр копируется из исходной области памяти в локальную память процедуры, располагаемую обычно в стековом сег­менте. В первом случае вызываемая процедура работает с оригинальными значе­ниями параметров и их изменения сразу же видны вызывающей процедуре. Во втором случае вызываемая процедура работает с копиями значений параметров, и их изменения никак не влияют на значение оригиналов этих переменных в вы­зывающей процедуре. Эти обстоятельства весьма существенны для RPC.

Решение о том, какой механизм передачи параметров использовать, принима­ется разработчиками языка. Иногда это зависит от типа передаваемых данных. В языке С, например, целые и другие скалярные данные всегда передаются по значению, а массивы — по ссылке.

Рисунок 1 иллюстрирует передачу параметров вызываемой процедуре: стек до выполнения вызова write (а), стек во время выполнения процедуры (6), стек по­сле возврата в вызывающую программу (в).

Рис.1 Передача параметров вызываемой процедуре: а —состояние стека

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

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

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

Механизм RPC достигает прозрачности следующим образом. Когда вызываемая процедура действительно является удаленной, в библиотеку процедур вместо локальной реализации оригинального кода процедуры помещается другая вер­сия процедуры, называемая клиентским стабом (stub — заглушка). На удаленный компьютер, который выполняет роль сервера процедур, помещается оригиналь­ный код вызываемой процедуры, а также еще один стаб, называемый серверным стабом. Назначение клиентского и серверного стабов - организовать передачу параметров вызываемой процедуры и возврат значения процедуры через сеть, при этом код оригинальной процедуры, помещенной на сервер, должен быть пол­ностью сохранен. Стабы используют для передачи данных через сеть средства подсистемы обмена сообщениями, то есть существующие в ОС примитивы send и receive. Иногда в подсистеме обмена сообщениями выделяется программный модуль, организующий связь стабов с примитивами передачи сообщений, назы­ваемый модулем RPCRuntime.

Подобно оригинальной процедуре, клиентский стаб вызывается путем обычной передачи параметров через стек (как показано на рис. 1), однако затем вместо выполнения системного вызова, работающего с локальным ресурсом, происхо­дит формирование сообщения, содержащего имя вызываемой процедуры и ее па­раметры (рис. 2. ).

Рис 2.Выполнение удаленного вызова процедуры.

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

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

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

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

Формат сообщений RPC

Механизм RPC оперирует двумя типами сообщений: сообщениями-вызовами, с помощью которых клиент запрашивает у сервера выполнение определенной уда­ленной процедуры и передает ее аргументы; сообщениями-ответами, с помощью которых сервер возвращает результат работы удаленной процедуры клиенту.

С помощью этих сообщений реализуется протокол RPC, определяющий способ взаимодействия клиента с сервером. Протокол RPC обычно не зависит от транспортных протоколов, с помощью которых сообщения RPC доставляются по сети от клиента к серверу и обратно. При использования в сети стека протоколов TCP/IP это могут быть протоколы TCP или UDP, в локальных сетях часто ис­пользуется также NetBEUI/NetBIOS или IPX/SPX.

Типичный формат двух типов сообщений, используемых RPC, показан па рис. 3

Рис. 3 Формат сообщений RPC

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

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

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