Виклик віддалених процедур 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 і полягає в необхідності копіювання викликає програмою змінних в стек у вигляді значень, а потім копіювання тому після виконання виклику поверх оригінальних значень викликає процедури.

Рішення про те, який механізм передачі параметрів використовувати, приймається розробниками мови. Іноді це залежить від типу переданих даних. У мові С, наприклад, цілі та інші скалярні дані завжди передаються за значенням, а масиви - по посиланню.

Виклик віддалених процедур (RPC)

Рис. 3.1. а) Стек до виконання виклику read;
б) Стек під час виконання процедури;
в) Стек після повернення в зухвалу програму

Ідея, покладена в основу RPC, полягає в тому, щоб зробити виклик віддаленої процедури що виглядає по можливості також, як і виклик локальної процедури. Іншими словами - зробити RPC прозорим: викликає процедурі не потрібно знати, що викликається процедура знаходиться на іншій машині, і навпаки.

RPC досягає прозорості наступним шляхом. Коли викликається процедура дійсно є віддаленої, в бібліотеку поміщається замість локальної процедури інша версія процедури, звана клієнтським стаб (stub - заглушка). Подібно оригінальної процедурі, стаб викликається з використанням викликає послідовності (як на малюнку 3.1), так само відбувається переривання при зверненні до ядра. Тільки на відміну від оригінальної процедури він не поміщає параметри в регістри і не запитує у ядра дані, замість цього він формує повідомлення для відправки ядру віддаленої машини.

Етапи виконання RPC

Взаємодія програмних компонентів при виконанні віддаленого виклику процедури ілюструється малюнком 3.2. Після того, як клієнтський стаб був викликаний програмою-клієнтом, його першим завданням є заповнення буфера відправлені повідомленням. У деяких системах клієнтський стаб має єдиний буфер фіксованої довжини, що заповнюється кожного разу з самого початку при вступі кожного нового запиту. В інших системах буфер повідомлення являє собою пул буферів для окремих полів повідомлення, причому деякі з цих буферів вже заповнені. Цей метод особливо підходить для тих випадків, коли пакет має формат, що складається з великої кількості полів, але значення багатьох з цих полів не змінюються від виклику до виклику.

Потім параметри повинні бути перетворені у відповідний формат і вставлені в буфер повідомлення. До цього моменту повідомлення готове до передачі, тому виконується переривання за викликом ядра.

Виклик віддалених процедур (RPC)

Рис. 3.2. Remote Procedure Call

Коли ядро ​​отримує управління, воно перемикає контексти, зберігає регістри процесора і карту пам'яті (дескриптори сторінок), встановлює нову карту пам'яті, яка буде використовуватися для роботи в режимі ядра. Оскільки контексти ядра і користувача розрізняються, ядро ​​має точно скопіювати повідомлення в своє власне адресний простір, так, щоб мати до нього доступ, запам'ятати адресу призначення (а, можливо, і інші поля заголовка), а також воно має передати його мережевого інтерфейсу. На цьому завершується робота на клієнтській стороні. Включається таймер передачі, і ядро ​​може або виконувати циклічний опитування наявності відповіді, або передати управління планувальником, який обере будь-який інший процес на виконання. У першому випадку прискорюється виконання запиту, але відсутній мультипрограмування.

На стороні сервера надходять біти поміщаються приймаючої апаратурою або у вбудований буфер, або в оперативну пам'ять. Коли вся інформація буде отримана, генерується переривання. Обробник переривання перевіряє правильність даних пакета і визначає, якому стаб слід їх передати. Якщо жоден із Стабілізаційного не очікує цей пакет, обробник повинен або помістити його в буфер, або взагалі відмовитися від нього. Якщо є очікує стаб, то повідомлення копіюється йому. Нарешті, виконується переключення контекстів, в результаті чого відновлюються регістри і карта пам'яті, приймаючи ті значення, які вони мали в момент, коли стаб зробив виклик receive.

Тепер починає роботу серверний стаб. Він розпаковує параметри і поміщає їх відповідним чином в стек. Коли все готово, виконується виклик сервера. Після виконання процедури сервер передає результати клієнту. Для цього виконуються всі описані вище етапи, тільки в зворотному порядку.

Малюнок 3.3 показує послідовність команд, яку необхідно виконати для кожного RPC-виклику, а малюнок 3.4 - яка частка загального часу виконання RPC витрачається на виконання кожного їх описаних 14 етапів. Дослідження були проведені на мультипроцессорной робочої станції DEC Firefly, і, хоча наявність п'яти процесорів обов'язково вплинуло на результати вимірювань, наведена на малюнку гістограма дає загальне уявлення про процес виконання RPC.

Виклик віддалених процедур (RPC)

Рис. 3.3. Етапи виконання процедури RPC

Виклик віддалених процедур (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 повинен функціонувати правильно і у випадку відмов. Розглянемо наступні класи відмов:

Клієнт не може визначити місцезнаходження сервера, наприклад, у разі відмови потрібного сервера, або через те, що програма клієнта була скомпільована давно і використовувала стару версію інтерфейсу сервера. У цьому випадку у відповідь на запит клієнта надходить повідомлення, що містить код помилки. Втрачено запит від клієнта до сервера. Найпростіше рішення - через певний час повторити запит. Втрачено відповідь повідомлення від сервера клієнтові. Цей варіант складніше попереднього, так як деякі процедури не є Ідемпотентний. Ідемпотентний називається процедура, запит на виконання якої можна повторити кілька разів, і результат при цьому не зміниться. Прикладом такої процедури може бути читання файлу. Але ось процедура зняття деякої суми з банківського рахунку не є Ідемпотентний, і в разі втрати відповіді повторний запит може істотно змінити стан рахунку клієнта. Одним з можливих рішень є приведення всіх процедур до Ідемпотентний увазі. Однак на практиці це не завжди вдається, тому може бути використаний інший метод - послідовна нумерація всіх запитів клієнтським ядром. Ядро сервера запам'ятовує номер самого останнього запиту від кожного з клієнтів, і при отриманні кожного запиту виконує аналіз - чи є цей запит первинним або повторним. Сервер зазнав аварію після отримання запиту. Тут також важливо властивість Ідемпотентний, але на жаль не може бути застосований підхід з нумерацією запитів. У даному випадку має значення, коли відбулася відмова - до чи після виконання операції. Але клієнтське ядро ​​не може розпізнати ці ситуації, для нього відомо тільки те, що час відповіді вичерпано. Існує три підходи до цієї проблеми: Чекати до тих пір, поки сервер не перезавантажиться і намагатися виконати операцію знову. Цей підхід гарантує, що RPC був виконаний до кінця принаймні один раз, а можливо і більше. Відразу повідомити додатка про помилку. Цей підхід гарантує, що RPC був виконаний не більше одного разу. Третій підхід не гарантує нічого. Коли сервер відмовляє, клієнтові не надається ніякої підтримки. RPC може бути або не виконано взагалі, чи виконано багато разів. В усякому разі цей спосіб дуже легко реалізувати.

Жоден з цих підходів не є дуже привабливим. А ідеальний варіант, який би гарантував рівно одне виконання RPC, в загальному випадку не може бути реалізований з принципових міркувань. Нехай, наприклад, віддаленої операцією є друк деякого тексту, яка включає завантаження буфера принтера і установку одного біта в деякому регістрі принтера, в результаті якої принтер стартує. Аварія сервера може відбутися як за мікросекунду до, так і за мікросекунду після установки керуючого біта. Момент збою цілком визначає процедуру відновлення, але клієнт про момент збою дізнатися не може. Коротше кажучи, можливість аварії сервера радикально змінює природу RPC і ясно відображає різницю між централізованою і розподіленою системою. У першому випадку крах сервера веде до краху клієнта, і відновлення неможливе. У другому випадку дії з відновлення системи виконати і можливо, й необхідно.

Клієнт зазнав аварію після відсилання запиту. У цьому випадку виконуються обчислення результатів, яких ніхто не очікує. Такі обчислення називають "сиротами". Наявність сиріт може викликати різні проблеми: непродуктивні витрати процесорного часу, блокування ресурсів, підміна відповіді на поточний запит відповіддю на запит, який був виданий клієнтської машиною ще до перезапуску системи.

Як поступати з сиротами? Розглянемо 4 можливих рішення.

Знищення. До того, як клієнтський стаб посилає RPC-повідомлення, він робить відмітку в журналі, оповіщаючи про те, що він буде зараз робити. Журнал зберігається на диску або в іншій пам'яті, стійкої до збоїв. Після аварії система перезавантажується, журнал аналізується і сироти ліквідуються. До недоліків такого підходу відносяться, по-перше, підвищені витрати, пов'язані із записом про кожного RPC на диск, а, по-друге, можлива неефективність через появу сиріт другого покоління, породжених RPC-викликами, виданими сиротами першого покоління. Перевтілення. У цьому випадку всі проблеми вирішуються без використання запису на диск. Метод полягає у розподілі часу на послідовно пронумеровані періоди. Коли клієнт перезавантажується, він передає широкомовне повідомлення всім машинам про початок нового періоду. Після прийому цього повідомлення всі видалені обчислення ліквідуються. Звичайно, якщо мережа сегментована, то деякі сироти можуть і вціліти. М'яке перевтілення аналогічно попередньому випадку, за винятком того, що відшукуються і знищуються не всі вилучені обчислення, а тільки обчислення перезавантажується клієнта. Закінчення строку. Кожному запитом відводиться стандартний відрізок часу Т, протягом якого він повинен бути виконаний. Якщо запит не виконується за відведений час, то виділяється додатковий квант. Хоча це і вимагає додаткової роботи, але якщо після аварії клієнта сервер чекає протягом інтервалу Т до перезавантаження клієнта, то всі сироти обов'язково знищуються.

На практиці жоден із цих підходів не бажаний, більше того, знищення сиріт може погіршити ситуацію. Наприклад, нехай сирота заблокував один або більше файлів бази даних. Якщо сирота буде раптом знищений, то ці блокування залишаться, крім того знищені сироти можуть залишитися стояти в різних системних чергах, у майбутньому вони можуть ініціювати виконання нових процесів і т.п.


Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Реферат
36.6кб. | скачати


Схожі роботи:
Теорія проектування віддалених баз даних
Міжбібліотечний абонемент та доставка документів Обслуговування віддалених користувачів
Виклик дикій силі
Росія як виклик географії
Віддалений виклик методом RMI
Островський а. н. - Виклик дикій силі
Шекспір ​​у. - Виклик кинутий всьому світу
Особливості відпуску процедур дітям
Фінансові аспекти процедур банкрутства підприємств
© Усі права захищені
написати до нас