Реферати українською » Информатика, программирование » Виклик віддалених процедур (RPC)


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

Страница 1 из 2 | Следующая страница

Концепція віддаленого виклику процедур

Ідея виклику віддалених процедур (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. Сервер зазнав аварії після отримання запиту. Тут також важливо властивість идемпотентности, та на жаль може бути застосований підхід з нумерацією запитів. У разі має значення, коли стався відмова - до чи влітку після здійснення операції. Але клієнтське ядро неспроможна розпізнати ж усе, йому відомо тільки те, що час відповіді минув. Існує три підходи до цієї проблеми:
Страница 1 из 2 | Следующая страница

Схожі реферати:

Навігація