Реферат: Вызов удаленных процедур (RPC) - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Вызов удаленных процедур (RPC)

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Архив Zip, 51 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Вызов удаленных процедур (RPC) Концепция удаленн ого вызова процедур Идея вызова уд аленных процедур (Remote Procedure Call - RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы , выполняющейся на одной машине , на передачу управления и данных через сеть . Средства уд аленного вызова процедур предназначены для облегчения организации распределенных вычислений . Наибольша я эффективность использования RPC достигается в тех приложениях , в которых существует интерак тивная связь между удаленными компонентами с небольшим време н ем ответов и относительно малым количеством передаваемых да нных . Такие приложения называются RPC-ориентированны ми . Характерными чертами вызова локальных про цедур являются : · Асимметричность , то есть одна из взаимодействующих сторон является инициатором ; · Синхронность , то есть выполнение вызывающей процедуры при останавл ивается с момента выдачи запроса и возобн овляется только после возврата из вызываемой процедуры . Реализация удаленн ых вызовов существенно сложнее реализации выз овов локальных процедур . Н ачнем с того , что поскольку вызывающая и вызываемая пр оцедуры выполняются на разных машинах , то они имеют разные адресные пространства , и это создает проблемы при передаче параметров и результатов , особенно если машины не идентичны . Так как RPC не может р а ссчитывать на разделяемую память , то э то означает , что параметры RPC не должны соде ржать указателей на ячейки нестековой памяти и что значения параметров должны копиров аться с одного компьютера на другой . Следу ющим отличием RPC от локального вызова являет с я то , что он обязательно испо льзует нижележащую систему связи , однако это не должно быть явно видно ни в о пределении процедур , ни в самих процедурах . Удаленность вносит дополнительные проблемы . Вы полнение вызывающей программы и вызываемой ло кальной процед у ры в одной машине реализуется в рамках единого процесса . Но в реализации RPC участвуют как минимум два процесса - по одному в каждой машине . В случае , если один из них аварийно за вершится , могут возникнуть следующие ситуации : при аварии вызывающей процеду р ы удаленно вызванные процедуры станут "осиротевшими ", а при аварийном завершении удаленных пр оцедур станут "обездоленными родителями " вызывающи е процедуры , которые будут безрезультатно ожи дать ответа от удаленных процедур . Кроме того , существует ряд пробл ем , связанных с неоднородностью языков программ ирования и операционных сред : структуры данны х и структуры вызова процедур , поддерживаемые в каком-либо одном языке программирования , не поддерживаются точно так же во всех других языках . Эти и некоторые друг ие проблемы решает широко распространенная технология RPC, леж ащая в основе многих распределенных операцион ных систем . Базовые операции RPC Чтобы понять р аботу RPC, рассмотрим вначале выполнение вызова локальной процедуры в обычной машине , работаю щей авто номно . Пусть это , например , буд ет системный вызов count=read (fd,buf,nbytes); где fd - целое число , buf - массив символов , nbytes - целое число . Чтобы осуществить вызов , вызывающая проце дура заталкивает параметры в стек в обрат ном порядке (рисунок 3.1) . После того , как вызов read выполнен , он помещает возвращаемое значение в регистр , перемещает адрес возвра та и возвращает управление вызывающей процеду ре , которая выбирает параметры из стека , в озвращая его в исходное состояние . Заметим , что в языке С пар а метры мо гут вызываться или по ссылке (by name), или по значению (by value). По отношению к вызываемой проц едуре параметры-значения являются инициализируемыми локальными переменными . Вызываемая процедура мо жет изменить их , и это не повлияет на значение ори г иналов этих перемен ных в вызывающей процедуре . Если в вызываемую процедуру передается указатель на переменную , то изменение значе ния этой переменной вызываемой процедурой вле чет изменение значения этой переменной и для вызывающей процедуры . Этот факт весь ма существенен для RPC. Существует также другой механизм передачи параметров , который не используется в язы ке С . Он называется call-by-copy/restore и состоит в н еобходимости копирования вызывающей программой п еременных в стек в виде значений , а за тем копи рования назад после выполнения вызова поверх оригинальных значений вызывающей процедуры . Решение о том , какой механизм передачи параметров использовать , принимается разработчик ами языка . Иногда это зависит от типа передаваемых данных . В языке С , например, целые и другие скалярные данные вс егда передаются по значению , а массивы - по ссылке . Рис . 3.1. а ) Стек до выполнения вызова read; б ) С тек во время выполнения процедуры ; в ) Сте к после возврата в вызывающую программу Идея , положенная в основу RPC, состоит в том , чтобы сделать вызов удаленной процед уры выглядящим по возможности также , как и вызов лока льной процедуры . Другими сл овами - сделать RPC прозрачным : вызывающей процедуре не требуется знать , что вызываемая процед ура находится на другой машине , и наоборот . RPC достигает прозрачности следующим путем . Когда вызываемая процедура действительно являе тся удаленной , в библиотеку помещается вместо локальной процедуры другая версия п роцедуры , называемая клиентским стабом (stub - заглушка ). Подобно оригинальной процедуре , стаб вызывае тся с использованием вызывающей последовательнос ти (как на рисунке 3.1), так же п роисходит прерывание при обращении к ядру . Только в отличие от оригинальной процедуры он не помещает параметры в регистры и не запрашивает у ядра данные , вместо этого он формирует сообщение для отправки ядру удаленной машины . Этапы выполнения RPC Взаимодействие про граммных компонентов при выполнении удаленного вызова процедуры иллюстрируется рисунком 3.2. Посл е того , как клиентский стаб был вызван программой-клиентом , его первой задачей являетс я заполнение буфера отправляемым сообщением . В некотор ы х системах клиентский с таб имеет единственный буфер фиксированной дл ины , заполняемый каждый раз с самого начал а при поступлении каждого нового запроса . В других системах буфер сообщения представляе т собой пул буферов для отдельных полей сообщения , причем н екоторые из эт их буферов уже заполнены . Этот метод особе нно подходит для тех случаев , когда пакет имеет формат , состоящий из большого числа полей , но значения многих из этих пол ей не меняются от вызова к вызову . Затем параметры должны быть преобразованы в соответствующий формат и вставлены в буфер сообщения . К этому моменту сооб щение готово к передаче , поэтому выполняется прерывание по вызову ядра . Рис . 3.2. Remote Procedure Call Когда я дро получает управление , оно переключает конт ексты , сохраняет регистры процессора и карту памяти (дескрипторы страниц ), устанавливает но вую карту памяти , которая будет использо ваться для работы в режиме ядра . Поскольку контексты ядра и пользователя различаются , ядро должно точно скопировать сообщение в свое собственное адресное пространство , так , чтобы иметь к нему доступ , запомнить адрес назначения (а , возможно , и друг и е поля заголовка ), а также оно долж но передать его сетевому интерфейсу . На эт ом завершается работа на клиентской стороне . Включается таймер передачи , и ядро может либо выполнять циклический опрос наличия ответа , либо передать управление планировщику , кото р ый выберет какой-либо друго й процесс на выполнение . В первом случае ускоряется выполнение запроса , но отсутствуе т мультипрограммирование . На стороне сервера поступающие биты п омещаются принимающей аппаратурой либо во вст роенный буфер , либо в оперативную п амя ть . Когда вся информация будет получена , г енерируется прерывание . Обработчик прерывания про веряет правильность данных пакета и определяе т , какому стабу следует их передать . Если ни один из стабов не ожидает этот пакет , обработчик должен либо поместить е го в буфер , либо вообще отказ аться от него . Если имеется ожидающий стаб , то сообщение копируется ему . Наконец , вып олняется переключение контекстов , в результате чего восстанавливаются регистры и карта па мяти , принимая те значения , которые они им ели в моме н т , когда стаб сдела л вызов receive. Теперь начинает работу серверный стаб . Он распаковывает параметры и помещает их соответствующим образом в стек . Когда все готово , выполняется вызов сервера . После вып олнения процедуры сервер передает результаты клиенту. Для этого выполняются все описа нные выше этапы , только в обратном порядке . Рисунок 3.3 показывает последовательность коман д , которую необходимо выполнить для каждого RPC-вызова , а рисунок 3.4 - какая доля общего в ремени выполнения RPC тратится на выполне ние каждого их описанных 14 этапов . Исследования были проведены на мультипроцессорной рабочей станции DEC Firefly, и , хотя наличие пяти процессоров обязательно повлияло на результаты измерений , приведенная на рисунке гистограмма дает общее представление о процессе выполн ения RPC. Рис . 3.3. Этапы выполнения процедуры RPC Рис . 3.4. Распределение времени межд у 14 этапами выполнения RPC 1. Вызов стаба 2. Подготовить буфер 3. Упаковать параметры 4. За полнить поле заголовк а 5. Вычислить контрольную сумму в сообщении 6. Прерывание к ядру 7. Очередь пакета на выполнени е 8. Передача сообщения контроллеру по шине QBUS 9. Время передачи по сети Ethernet 10. Получить пакет от контролле ра 11. Процедура обработки преры вания 12. Вычисление контрольной суммы 13. Переключение контекста в пр остранство пользователя 14. Выполнение серверного стаба Динамическое связ ывание Рассмотрим вопрос о том , как клиент задает месторасположени е сервера . Одним из методов решения этой проблемы является непосредственное использо вание сетевого адреса сервера в клиентской программе . Недостаток такого подхода - его ч резвычайная негибкость : при перемещении сервера , или при увеличении числа серверов , или при изменении интерфейса во всех э тих и многих других случаях необходимо пе рекомпилировать все программы , которые использова ли жесткое задание адреса сервера . Для тог о , чтобы избежать всех этих проблем , в некоторых распределенных системах используется т ак называемое динамическое с вязывание . Начальным моментом для динамического связ ывания является формальное определение (специфика ция ) сервера . Спецификация содержит имя файл-се рвера , номер версии и список процедур-услуг , предоставляемых данным сервером для клиентов (рисунок 3.5). Дл я каждой процедуры даетс я описание ее параметров с указанием того , является ли данный параметр входным или выходным относительно сервера . Некоторые пар аметры могут быть одновременно входными и выходными - например , некоторый массив , который посылается кли е нтом на сервер , модифицируется там , а затем возвращается обра тно клиенту (операция copy/ restore). Рис . 3.5. С пецификация сервера RPC Формальная спецификация сервера используется в качестве исходных данных для программы-генератора ста бов , которая создает как клиентские , так и серверные стабы . Затем они помещаются в соответствующие библиотеки . Когда пользова тельская (клиентская ) программа вызывает любую процедуру , определенную в спецификации сервера , соответствующая стаб-процедура связывается с двоичным к о дом программы . Аналогичн о , когда компилируется сервер , с ним связы ваются серверные стабы . При запуске сервера самым первым его действием является передача своего серверног о интерфейса специальной программе , называемой binder'ом . Этот процесс , известный ка к пр оцесс регистрации сервера , включает передачу сервером своего имени , номера версии , уникальн ого идентификатора и описателя местонахождения сервера . Описатель системно независим и мож ет представлять собой IP, Ethernet, X.500 или еще какой-либо адрес . Кр о ме того , он может содержать и другую информацию , например , отн осящуюся к аутентификации . Когда клиент вызывает одну из удаленн ых процедур первый раз , например , read, клиентский стаб видит , что он еще не подсоединен к серверу , и посылает сообщение binder-п рограмме с просьбой об импорте интерф ейса нужной версии нужного сервера . Если т акой сервер существует , то binder передает описател ь и уникальный идентификатор клиентскому стаб у . Клиентский стаб при посылке сообщения с запросом использует в качестве адреса описатель . В сообщении содержатся парам етры и уникальный идентификатор , который ядро сервера использует для того , чтобы направ ить поступившее сообщение в нужный сервер в случае , если их несколько на этой машине . Этот метод , заключающийся в импорте /эк спор те интерфейсов , обладает высокой гибк остью . Например , может быть несколько серверов , поддерживающих один и тот же интерфейс , и клиенты распределяются по серверам слу чайным образом . В рамках этого метода стан овится возможным периодический опрос серверов , а н ализ их работоспособности и , в случае отказа , автоматическое отключение , чт о повышает общую отказоустойчивость системы . Этот метод может также поддерживать аутентифи кацию клиента . Например , сервер может определи ть , что он может быть использован только кли е нтами из определенного списк а . Однако у динамического связывания имеются недостатки , например , дополнительные накладные расходы (временные затраты ) на экспорт и импорт интерфейсов . Величина этих затрат мо жет быть значительна , так как многие клиен тские про цессы существуют короткое время , а при каждом старте процесса процедура импорта интерфейса должна быть снова вып олнена . Кроме того , в больших распределенных системах может стать узким местом программ а binder, а создание нескольких программ аналогично го на з начения также увеличивает н акладные расходы на создание и синхронизацию процессов . Семантика RPC в случае отказов В идеале RPC долж ен функционировать правильно и в случае о тказов . Рассмотрим следующие классы отказов : 1. Клиент не может определить местона хождения сервера , например , в случае о тказа нужного сервера , или из-за того , что программа клиента была скомпилирована давно и использовала старую версию интерфейса сервера . В этом случае в ответ на запр ос клиента поступает сообщение , содержащее ко д ошибк и . 2. Потерян запрос от кл иента к серверу . Самое простое решение - че рез определенное время повторить запрос . 3. Потеряно ответное сообще ние от сервера клиенту . Этот вариант сложн ее предыдущего , так как некоторые процедуры не являются идемпотентными . Идем потентной называется процедура , запрос на выполнение которой можно повторить несколько раз , и результат при этом не изменится . Примером такой процедуры может служить чтение файла . Но вот процедура снятия некоторой суммы с банковского счета не является иде м потентной , и в случае потери ответа повторный запрос может существенно изм енить состояние счета клиента . Одним из во зможных решений является приведение всех проц едур к идемпотентному виду . Однако на прак тике это не всегда удается , поэтому может быть испол ь зован другой метод - последовательная нумерация всех запросов клие нтским ядром . Ядро сервера запоминает номер самого последнего запроса от каждого из клиентов , и при получении каждого запроса выполняет анализ - является ли этот запрос первичным или повтор н ым . 4. Сервер потерпел аварию после получения запроса . Здесь также важно свойство идемпотентности , но к сожалению не может быть применен подход с нумерацие й запросов . В данном случае имеет значение , когда произошел отказ - до или после выполнения операции . Но клиентское ядро не может распознать эти ситуации , для него известно только то , что время ответа истекло . Существует три подхода к этой про блеме : · Ждать до тех пор , пока сервер не перезагрузится и пытаться выполнить операцию снова . Этот подхо д гарант ирует , что RPC был выполнен до конца по крайней мере один раз , а в озможно и более . · Сразу сообщить прило жению об ошибке . Этот подход гарантирует , что RPC был выполнен не более одного раза . · Третий подход не гарантирует ничего . Когда сервер отказывает , клиенту не оказывается никакой поддержки . RPC может быть или не выполнен вообще , и ли выполнен много раз . Во всяком случае этот способ очень легко реализовать . Ни один из этих подходов не является очень привлекате льным . А идеальный вариант , который бы гар а нтировал ровно одно выполнение RPC, в об щем случае не может быть реализован по принципиальным соображениям . Пусть , например , уд аленной операцией является печать некоторого текста , которая включает загрузку буфера прин тера и установку одного бита в некотор о м управляющем регистре принтера , в результате которой принтер стартует . Авария сервера может произойти как за микросеку нду до , так и за микросекунду после ус тановки управляющего бита . Момент сбоя целико м определяет процедуру восстановления , но кли ент о мо м енте сбоя узнать не может . Короче говоря , возможность аварии сервера радикально меняет природу RPC и ясно отражает разницу между централизованной и распределенной системой . В первом случае крах сервера ведет к краху клиента , и восс тановление невозможно . В о втором слу чае действия по восстановлению системы выполн ить и возможно , и необходимо . 1. Клиент потерпел аварию после отсылк и запроса . В этом случае выполняются вычис ления результатов , которых никто не ожидает . Такие вычисления называют "сиротами ". Наличи е сирот может вызвать различные пробл емы : непроизводительные затраты процессорного вре мени , блокирование ресурсов , подмена ответа на текущий запрос ответом на запрос , который был выдан клиентской машиной еще до перезапуска системы . Как поступать с сиротам и ? Рассмотрим 4 возможных решения . · Уничтожение. До того , как клиентский стаб посылает RPC-сообщение , он делает отметку в журнале , оповещая о том , что он будет сейчас делать . Журнал хранится на диске или в другой памят и , устойчивой к сбоям . После аварии с истема перезагружается , журнал анализируется и сироты ликвидируются . К недостаткам такого подхода относятся , во-первых , повышенные затраты , связанные с записью о каждом RPC на диск , а , во-вторых , возможная неэффективность из-за появления сирот второго по к олени я , порожденных RPC-вызовами , выданными сиротами п ервого поколения . · Перевоплоще ние . В этом случае все пр облемы решаются без использования записи на диск . Метод состоит в делении времени на последовательно пронумерованные периоды . Ког да клиент переза гружается , он передает широковещательное сообщение всем машинам о начале нового периода . После приема этого сообщения все удаленные вычисления ликвидируют ся . Конечно , если сеть сегментированная , то некоторые сироты могут и уцелеть . · Мягкое перевоплощение аналогично предыдущем у случаю , за исключением того , что отыскив аются и уничтожаются не все удаленные выч исления , а только вычисления перезагружающегося клиента . · Истечение срока . Каждому запросу отводит ся стандартный отрезок времени Т , в течени е которог о он должен быть выполнен . Если запрос не выполняется за отведенное время , то выделяется дополнительный квант . Х отя это и требует дополнительной работы , н о если после аварии клиента сервер ждет в течение интервала Т до перезагрузки клиента , то все сироты о бязательно уничтожаются . На практике ни один из этих подходов не желателен , б олее того , уничтожение сирот может усугубить ситуацию . Например , пусть сирота заблокировал один или более файлов базы данных . Ес ли сирота будет вдруг уничтожен , то эти блокировки останутся , кроме того уничтоже нные сироты могут остаться стоять в разли чных системных очередях , в будущем они мог ут вызвать выполнение новых процессов и т. п .
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
А знаете ли вы, что собаки лающие на вас из подворотни, в следующей жизни становятся работниками регистратуры?
Anekdot.ru

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

Обратите внимание, реферат по программированию "Вызов удаленных процедур (RPC)", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru