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

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

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

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

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

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

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

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