Fix: чи не запускається служба "Віддалений виклик процедур (RPC)". Виклик віддалених процедур (rpc - Remote Procedure Call) Віддалений доступ rpc

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

Ідея виклику віддалених процедур (Remote Procedure Call - RPC) полягає в розширенні добре відомого і зрозумілого механізму передачі управління і даних усередині програми, що виконується на одній машині, на передачу управління і даних через мережу. Засоби віддаленого виклику процедур призначені для полегшення організації розподілених обчислень. Найбільша ефективність використання RPC досягається в тих додатках, в яких існує інтерактивний зв'язок між віддаленими компонентами з невеликим часом відповідей і відносно малою кількістю переданих даних. Такі додатки називаються RPC-орієнтованими.

Характерними рисами виклику локальних процедур є:

Асиметричність, тобто одна з взаємодіючих сторін є ініціатором; Синхронність, тобто виконання викликає процедури при зупиняється з моменту видачі запиту і відновлюється тільки після повернення з викликається процедури.

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

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

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

Базові операції RPC

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

Count \u003d 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

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

На стороні сервера надходять біти поміщаються приймаючої апаратурою або у вбудований буфер, або в оперативну пам'ять. Коли вся інформація буде отримана, генерується переривання. Оброблювач переривання перевіряє правильність даних пакета і визначає, якому стаб слід їх передати. Якщо жоден з стаб не очікує цей пакет, обробник повинен або помістити його в буфер, або взагалі відмовитися від нього. Якщо є очікує стаб, то повідомлення копіюється йому. Нарешті, виконується перемикання контекстів, в результаті чого відновлюються регістри і карта пам'яті, приймаючи ті значення, які вони мали в момент, коли стаб зробив виклик 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 передає описувач і унікальний ідентифікатор клієнтському стаб.

Клієнтський стаб при посилці повідомлення із запитом використовує в якості адреси описувач. У повідомленні містяться параметри і унікальний ідентифікатор, який ядро \u200b\u200bсервера використовує для того, щоб направити надійшло повідомлення в потрібний сервер у випадку, якщо їх декілька на цій машині.

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

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

Семантика RPC у разі відмов

В ідеалі RPC повинен функціонувати правильно і в разі відмов. Розглянемо наступні класи відмов:

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

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

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

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

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

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

Багато користувачів комп'ютерних систем чули про такі поняття, як віддалені процедури, виклик віддалених процедур або RPC. Ось тільки далеко не всі уявляють собі, що це за технології, як вони працюють і для чого потрібні. А адже багато хто з тих, хто відключив дану службу в Windows-системах, часто можуть отримувати і помилки, пов'язані з критичним збоїв. Про це та багато іншого далі піде мова.

Віддалений виклик процедур: що це?

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

Однак віддалені процедури (виклик віддалених процедур), що позначаються як RPC (скорочення від англійського Remote Procedure Call), можна віднести не тільки до віддалених комп'ютерів. На локальному рівні такі технології теж застосовуються. В якості найпростішого прикладу можна навести виклик певної функції однієї програми з іншої програми за допомогою взаємодії через спеціальні бібліотеки.

Крім того, абсолютно у всіх версіях Windows є така служба, а при її відключенні або відмову працездатності модифікація XP не працює взагалі.

Принцип дії

Як правило, служба «Віддалений виклик процедур RPC» для роботи в режимі клієнт-сервер вимагає наявності як мінімум двох основних компонентів: мережевого протоколу для обміну даними та мови сериализации (переведення якогось процесу або інформаційної структури даних в бітову послідовність).

Архітектури можуть бути абсолютно різними і відрізняються за своїми можливостями. Але для обміну даними на так званому транспортному рівні найчастіше застосовуються протоколи UDP і TCP, рідше - HTTP.

Щоб не вдаватися в технічні аспекти, найпростішим поясненням принципу роботи таких технологій може стати наступні приклад: клієнтський процес формує запит серверу з описом обраної процедури з зазначеними параметрами і відправляє його, після чого сервер виконує необхідну директиву і відправляє клієнту відповідь, який відображається на клієнтської машині. Однак сам серверний обробник знаходиться, так би мовити, в режимі очікування і активується тільки в моменти отримання клієнтських запитів. При цьому зовсім не обов'язково, щоб виконання схеми «запит-відповідь» проводилося негайно.

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

Дистанційні процедури (виклик віддалених процедур): характерні риси та реалізації

Таким чином, можна виділити дві головні особливості названих технологій:

асиметричність (ініціація виконання віддаленої процедури тільки однієї зі сторін);
синхронність (припинення викликає процедури з моменту ініціації запиту і відновлення після відправки відповіді).

Що ж стосується реалізацій, віддалені процедури (виклик віддалених процедур) сьогодні використовують кілька базових технологій, серед яких найбільш широко застосовуються такі:

DCE / RPC - бінарний протокол на основі TCP / IP, SMB / SIFC і \u200b\u200bт. Д .;
DCOM - об'єктно-орієнтоване додаток з можливістю передачі посилань на об'єкти і викликом методів їх обробки;
JSON-RPC - текстовий протокол, заснований на HTTP;
.NET Remoting - бінарний протокол на основі UDP, TCP і HTTP;
JAVA RMI;
SOAP;
XML RPC;
SUN RPC;
ZeroC ICE;
Routix.RPC і ін.

Проблеми і завдання

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

Другий момент пов'язаний з тим, що віддалені процедури (виклик віддалених процедур) використовують не один процес, як на локальному рівні, а два (на клієнтській машині і на сервері). Тому аварійне завершення програми на одному з терміналів може викликати таку ж реакцію і на іншому.

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

Основні типи підсистем

Віддалений виклик процедур Windows 10 або будь-який інший системи рангом нижче на увазі використання спеціальних підсистем:

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

Які типи програм вимагають виконання RPC?

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

Але серед усіх відомих компонентів Windows-систем можна відзначити службу факсів, служби криптографії, реєстрацію помилок, довідку і підтримку, доступ до пристроїв HID, службу повідомлень (Messenger), адміністрування дисків і логічних розділів, управління знімними накопичувачами, аудіосистему, інсталятор Windows і ще бозна-що.

Здається, цього списку досить, щоб зрозуміти, наскільки багато компонентів системи, та й сам користувач, залежні від цієї служби.

На що впливає RPC

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

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

Чи можна відключити цю службу

За великим рахунком, багато хто намагався (і намагаються) службу "Віддалений виклик процедур» відключити. Робити це категорично забороняється. В общем-то, і сама система при здійсненні такої спроби зробити цього не дасть, видавши відповідне повідомлення.

Але не всі знають, що в розділі служби (services.msc) є ще така штука, як «Локатор віддаленого виклику процедур RPC». Ось його-то якраз і можна відключити безболісно для системи. Додатки, які можуть його використовувати в своїй роботі, самостійно викличуть сервіс при необхідності.

Усунення збоїв і помилок

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

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

Якщо це не допоможе, але під рукою є інсталяційний або відновлювальний диск системи, можна запустити командну консоль з правами адміністратора (завантажуватися з диска не потрібно) і прописати в ній такі команди:

cd z: \\ i386 (Z - літера оптичного приводу);
expand explorer.ex_% TEMP% \\ explorer.exe;
expand svchost.ex_% TEMP% \\ svchost.exe.

Після цього запускаємо «Диспетчер завдань» (Ctrl + Del + Alt або taskmgr в меню «Виконати») і завершуємо процес Explorer.exe.

У «Диспетчері» зупиняємо всі процеси svhost.exe, після чого протягом 60 секунд потрібно встигнути в командою рядку ввести рядок copy% TEMP% \\ svchost.exe% systemroot% \\ system32 / y.

Нарешті, якщо є доступ до редактора системного реєстру (Regedit) відновлений, потрібно пройти по гілці HKCC через розділи SYSTEM і CurrentControlSet і дістатися до параметра CSConfigFlags, змінивши його значення на нуль.

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

висновок

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

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

Програми, які спілкуються через мережу, потребують механізмі зв'язку. На нижньому рівні по надходженні пакетів подається сигнал, що обробляється мережевий програмою обробки сигналів. На верхньому рівні працює механізм rendezvous (рандеву), прийнятий в мові Ада. В NFS використовується механізм виклику віддалених процедур (RPC), в якому клієнт взаємодіє з сервером (див. Малюнок 1). Відповідно до цим процесом клієнт спочатку звертається до процедури, яка посилає запит на сервер. Після прибуття пакета із запитом сервер викликає процедуру його розтину, виконує запитувану послугу, посилає відповідь, і управління повертається клієнтові.

Інтерфейс RPC можна уявити що складається з трьох рівнів:

Верхній рівень повністю "прозорий". Програма цього рівня може, наприклад, містити звернення до процедури rnusers (), що повертає число користувачів на віддаленій машині. Вам не потрібно знати про використання механізму RPC, оскільки ви робите звернення в програмі.
Середній рівень призначений для найбільш загальних додатків. RPC-викликами на цьому рівні займаються підпрограми registerrpc () і callrpc (): registerrpc () отримує общесіс темний код, а callrpc () виконує виклик віддаленої процедури. Виклик rnusers () реалізується за допомогою цих двох підпрограм.
Нижній рівень використовується для більш складних завдань, що змінюють умовчання на значення параметрів процедур. На цьому рівні ви можете явно маніпулювати гніздами, використовуваними для передачі RPC-повідомлень.

Як правило, вам слід користуватися верхнім рівнем і уникати використання нижніх рівнів без особливої \u200b\u200bнеобхідності.

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

RPC (Remote Procedure Call, Сервіс виклику віддалених процедур) являє собою інтерфейс між віддаленими користувачами і певними програмами хоста, які запускаються за запитами цих користувачів. Сервіс RPC будь-якого хоста, як правило, надає клієнтам комплекс програм. Кожна з таких програм полягає, в свою чергу, з однієї або декількох віддалених процедур. Наприклад, сервіс віддаленої файлової системи NFS, який побудований на виклики RPC, може складатися тільки з двох програм: наприклад, одна програма взаємодіє з високорівневими користувача інтерфейсами, а інша - з низькорівневими функціями введення-виведення.

У кожному виклику віддаленої процедури беруть участь дві сторони: активний клієнт, який відправляє запит виклику процедури на сервер, і сервер, який відправляє клієнту відповідь.

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

Протокол RPC побудований на моделі викликів віддалених процедур, подібного механізму викликів локальних процедур. При виклику локальної процедури ви ставите аргументи в певне місце пам'яті, в стек або змінні оточення і передаєте управління процесом за певною адресою. Після завершення роботи ви читаєте результати за конкретною адресою і продовжуєте свій процес.

У разі роботи з віддаленій процедурою, основна відмінність полягає в тому, що виклик віддаленої функції обслуговують два процеси: клієнтський процес і серверний процес.

Процес клієнта відправляє серверу повідомлення, в яке включені параметри викликається процедури і очікує відповідного повідомлення з результатами її роботи. При отриманні відповіді результат зчитується, і процес продовжує роботу. З боку сервера процес-обробник викликів знаходиться в стані очікування, і, при надходженні повідомлення, зчитує параметри процедури, виконує її, відправляє відповідь і стає в стан очікування наступного виклику.

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

Однак між викликами локальних і віддалених процедур є кілька важливих відмінностей:

Обробка помилок. Клієнт в будь-якому випадку повинен отримувати повідомлення про помилки, що виникають при викликах віддалених процедур на сервері або в мережі.
Глобальні змінні. Оскільки сервер не має доступу до адресного простору клієнта, при викликах віддалених процедур не можна використовувати приховані параметри у вигляді глобальних змінних.
Продуктивність. Швидкість виконання віддалених процедур, як правило на один або два порядки нижче швидкості виконання аналогічних локальних процедур.
Аутентифікація. Оскільки виклики віддалених процедур відбуваються по мережі, необхідно використовувати механізми аутентифікації клієнта.

Принципи побудови протоколу.

Протокол RPC може використовувати кілька різних транспортних протоколів. В обов'язки RPC-протоколу входить лише забезпечення стандартів і інтерпретація передачі повідомлень. Достовірність і надійність передачі повідомлень цілком забезпечується транспортним рівнем.

Однак RPC може контролювати вибір і деякі функції транспортного протоколу. Як приклад взаємодії між RPC і транспортним протоколом розглянемо процедуру призначення RPC-порту роботи прикладного процесу через RPC - Portmapper.

Ця функція динамічно (на вимогу) призначає з'єднанню RPC певний порт. Функція Portmapper використовується досить часто, оскільки набір зарезервованих для RPC транспортних портів обмежений, а кількість процесів, які потенційно можуть одночасно працювати дуже високо. Portmapper, наприклад, викликається при виборі портів взаємодії клієнта і сервера системи NFS.

Сервіс Portmapper використовує механізм широкомовних повідомлень RPC на певний порт - III. На цей порт клієнт відправляє широковещательное повідомлення запиту порту певного сервісу RPC. Сервіс Portmapper обробляє таксі повідомлення, визначає адресу локального сервісу RPC і відправляє клієнту відповідь. Сервіс RPC Portmapper може працювати як з TCP, так і з UDP-протоколами.

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

Примітка.

Прикладні завдання можуть розглядати RPC-протокол як певну процедуру виклику функції по мережі JSR (Jump Subroutine Instruction).

Для роботи RPC-протоколу необхідно виконання наступних умов:

Унікальна ідентифікації всіх віддалено викликаються процедур на даному хості. RPC-запити містять три поля ідентифікаторів - номер віддаленої програми (сервісу), номер версії віддаленої програми і номер віддаленої процедури зазначеної програми. Номер програми призначається виробником сервісу, номер процедури вказує на конкретну функцію даного сервісу
Ідентифікація версії RPC-протоколу. RPC-повідомлення містять поле версії RPC-протоколу. Вона використовується для узгодження форматів переданих параметрів при роботі клієнта з різними версіями RPC.
Надання механізмів аутентифікації клієнта на сервері. RPC-протокол забезпечує процедуру аутентифікації клієнта в сервісі, і, в разі необхідності, при кожному запиті або написанні відповіді клієнту. Крім того, RPC дозволяє використовувати різні додаткові механізми безпеки.

RPC може використовувати чотири типи механізмів аутентифікації:

AUTH_NULL - без використання аутентифікації
AUTH_UNIX - аутентифікація за стандартом UNIX
AUTH_SHORT - аутентифікація за стандартом UNIX з власною структурою кодування
AUTH_DES - аутентифікація за стандартом DES

Ідентифікація повідомлень відповіді на відповідні запити. Відповідні повідомлення RPC містять ідентифікатор запиту, на підставі якого вони були побудовані. Цей ідентифікатор можна назвати ідентифікатором транзакції виклику RPC. Даний механізм особливо необхідний при роботі в асинхронному режимі і при виконанні послідовності з декількох RPC-викликів.
Ідентифікація помилок роботи протоколу. Всі мережеві або серверні помилки мають унікальні ідентифікатори, за якими кожен з учасників з'єднання може визначити причину збою в роботі.

Структури повідомлень протоколу

При передачі RPC-повідомлень поверх транспортного протоколу, кілька RPC-повідомлень можуть розташовуватися всередині одного транспортного пакета. Для того щоб відокремлювати одне повідомлення від іншого, використовується маркер записи (RM - Record Marker). Кожне RPC-повідомлення "маркується" рівно одним RM.

RPC-повідомлення може складатися з декількох фрагментів. Кожен фрагмент складається з чотирьох байт заголовка і (від 0 до 2 ** 31-1) даних. Перший біт заголовка вказує, чи є даний фрагмент останнім, а решта 31 біт вказують довжину пакета даних.

Структура RPC формально описана на мові опису та подання форматів даних - XDR з доповненнями, що стосуються опису процедур. Можна навіть сказати, що мова опису RPC є розширенням XDR, доповненим роботою з процедурами.

Структура RPC-пакета виглядає наступним чином:

Структура відповіді (reply_body) може містити або структуру, передану в разі помилки (тоді вона містить код помилки), або структуру успішної обробки запиту (тоді вона містить повертаються дані).

Програмний інтерфейс високого рівня.

Використання підпрограм в програмі - традиційний спосіб структурувати завдання, зробити її більш зрозумілою. Найбільш часто використовувані підпрограми збираються в бібліотеки, де можуть використовуватися різними програмами. В даному випадку мова йде про локальне (місцеве) виклику, т. Е. І викликає, і викликається об'єкти працюють в рамках однієї програми на одному комп'ютері.

У разі віддаленого виклику процес, що виконується на одному комп'ютері, запускає процес на віддаленому комп'ютері (т. Е. Фактично запускає код процедури на віддаленому комп'ютері). Очевидно, що віддалений виклик процедури істотно відрізняється від традиційного локального, проте з точки зору програміста такі відмінності практично відсутні, т. Е. Архітектура віддаленого виклику процедури дозволяє зімітувати виклик локальної.

Однак якщо в разі локального виклику програма передає параметри в спричинюється процедуру і отримує результат роботи через стек або загальні області пам'яті, то в разі віддаленого виклику передача параметрів перетворюється в передачу запиту по мережі, а результат роботи знаходиться у отриманому відгуку.

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

Віддалений виклик процедури включає наступні кроки:

Програма-клієнт здійснює локальний виклик процедури, званої заглушкою (stub). При цьому клієнту "здається", що, викликаючи заглушку, він виробляє власне виклик процедури-сервера. І дійсно, клієнт передає заглушці необхідні параметри, а вона повертає результат. Однак справа йде не зовсім так, як це собі уявляє клієнт. Завдання заглушки - прийняти аргументи, які призначаються віддаленої процедури, можливо, перетворити їх в якийсь стандартний формат і сформувати мережевий запит. Упаковка аргументів і створення мережевого запиту називається складанням (marshalling).
Мережевий запит пересилається по мережі на віддалену систему. Для цього в заглушці використовуються відповідні виклики, наприклад, розглянуті в попередніх розділах. Зауважимо, що при цьому можуть бути використані різні транспортні протоколи, причому не тільки сімейства TCP / IP.
На віддалений хост все відбувається в зворотному порядку. Заглушка серверу очікує запит і при отриманні витягує параметри - аргументи виклику процедури. Витяг (unmarshalling) може включати необхідні перетворення (наприклад, зміни порядку розташування байтів).
Заглушка виконує виклик справжньою процедури-сервера, якої адресовано прохання клієнта, передаючи їй отримані по мережі аргументи.
Після виконання процедури управління повертається в заглушку сервера, передаючи їй необхідні параметри. Як і заглушка клієнта; заглушка сервера перетворює повернуті процедурою значення, формуючи мережеве повідомлення-відгук, який передається по мережі системі, від якої надійшов запит.
Операційна система передає отримане повідомлення заглушці клієнта, яка, після необхідного перетворення, передає значення (є значеннями, повернутими віддаленої процедурою) клієнту, який сприймає це як нормальний повернення з процедури.

Таким чином, з точки зору клієнта, він виробляє виклик віддаленої процедури, як він це зробив би для локальної. Те ж саме можна сказати і про сервер: виклик процедури відбувається стандартним чином, якийсь об'єкт (заглушка сервера) виробляє виклик локальної процедури і отримує повернені нею значення. Клієнт сприймає заглушку як спричинюється процедуру-сервер, а сервер приймає власну заглушку за клієнта.

Таким чином, заглушки складають ядро \u200b\u200bсистеми RPC, відповідаючи за всі аспекти формування та передачі повідомлень між клієнтом і віддаленим сервером (процедурою), хоча і клієнт і сервер вважають, що виклики відбуваються локально. У цьому-то і полягає основна концепція RPC - повністю сховати розподілений (мережевий) характер взаємодії в коді заглушок. Переваги такого підходу очевидні: і клієнт і сервер є незалежними від мережевої реалізації, обидва вони працюють в рамках якоїсь розподіленої віртуальної машини, І виклики процедур мають стандартний інтерфейс.

передача параметрів

Передача параметрів-значень не викликає особливих труднощів. В цьому випадку заглушка клієнта розміщує значення параметра в мережевому запиті можливо, виконуючи перетворення до стандартного вигляду (наприклад, змінюючи порядок проходження байтів). Набагато складніше йде справа з передачею покажчиків, коли параметр являє собою адресу даних, а не їх значення. Передача в запиті адреси позбавлена \u200b\u200bсенсу, так як віддалена процедура виконується в зовсім іншому адресному просторі. самим простим рішенням, Застосовуваним в RPC, є заборона клієнтам передавати параметри інакше, як за значенням, хоча це, безумовно, накладає серйозні обмеження.

Зв'язування (binding)

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

Знаходження віддаленого хоста з необхідним сервером
Знаходження необхідного серверного процесу на даному хості

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

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

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

Для передачі запиту клієнта також необхідно знати мережеву адресу хоста і номер порту, пов'язаний з програмою-сервером, що забезпечує необхідні процедури. Для цього використовується демон portmap (IM) (в деяких системах він називається rpcbind (IM)). Демон запускається на хості, який надає сервіс віддалених процедур, і використовує загальновідомий номер порту. При ініціалізації процесу-сервера він реєструє в portmap (IM) свої процедури і номери портів. Тепер, коли компанія HP вимагає знати номер порту для виклику конкретної процедури, він посилає запит на сервер portmap (IM), який, в свою чергу, або повертає номер порту, або перенаправляє запит безпосередньо сервера віддаленої процедури і після її виконання повертає клієнту відгук. У будь-якому випадку, якщо необхідна процедура існує, клієнт отримує від сервера portmap (IM) номер порту процедури, і подальші запити може робити вже безпосередньо на цей порт.

Обробка особливих ситуацій (exception)

Обробка особливих ситуацій при виклику локальних процедур не представляє особливої \u200b\u200bпроблеми. UNIX забезпечує обробку помилок процесів таких як розподіл на нуль, звернення до неприпустимою області пам'яті і т. Д. У разі виклику віддаленої процедури ймовірність виникнення помилкових ситуацій збільшується. До помилок сервера і заглушок додаються помилки, пов'язані, наприклад, з отриманням помилкового мережевого повідомлення.

Наприклад, при використанні UDP в якості транспортного протоколу проводиться повторна передача повідомлень після певного тайм-ауту. Клієнту повертається помилка, якщо, через певне число спроб, відгук від сервера так і не було отримано. У разі, коли використовується протокол TCP, клієнту повертається помилка, якщо сервер обірвав TCP-з'єднання.

семантика виклику

Виклик локальної процедури однозначно призводить до її виконання після чого управління повертається в головний програму. Інакше справа йде при виклику віддаленої процедури. Неможливо встановити, коли саме буде виконуватися процедура, чи буде вона виконана взагалі, а якщо буде, то яке число раз? Наприклад, якщо запит буде отриманий віддаленої системою після аварійного завершення програми сервера, процедура не буде виконана взагалі. Якщо клієнт при неотриманні відгуку після певного проміжку часу (тайм-ауту) повторно надсилає запит, то може створитися ситуація, коли відгук вже передається по мережі, а повторний запит знову береться на обробку віддаленої процедурою. В цьому випадку процедура буде виконана кілька разів.

Таким чином, виконання віддаленої процедури можна характеризувати наступній семантикою:

Один і тільки один раз. Даного поведінки (в деяких випадках найбільш бажаного) важко вимагати через можливих аварій сервера.
Максимум раз. Це означає, що процедура або взагалі не була виконана, або була виконана тільки один раз. Подібне твердження можна зробити при отриманні помилки замість нормального відгуку.
Хоча б раз. Процедура напевно було виконано один раз, але можливо і більше. Для нормальної роботи в такій ситуації віддалена процедура повинна мати властивість ідемпотентності (від англ. Idemponent). Цією властивістю володіє процедура, багаторазове виконання якої не викликає кумулятивних змін. Наприклад, читання файлу ідемпотентна, а щоб додати текст на файл - немає.

подання даних

Коли клієнт і сервер виконуються в одній системі на одному комп'ютері, проблем з несумісністю даних не виникає. І для клієнта і для сервера дані в двійковому вигляді представляються однаково. У разі віддаленого виклику справа ускладнюється тим, що клієнт і сервер можуть виконуватися на системах з різною архітектурою, мають різне уявлення даних (наприклад, представлення значення з плаваючою точкою, порядок проходження байтів і т. Д.)

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

Наприклад, формат представлення даних в RPC фірми Sun Microsystems наступний:

Порядок проходження байтів - Старший - останній
Подання значень з плаваючою точкою - IEEE
Представлення символу - ASCII

Мережа

За своєю функціональністю система RPC займає проміжне місце між рівнем додатки і транспортним рівнем. Відповідно до моделі OSI з цим положенням відповідають рівні уявлення і сеансу. Таким чином, RPC теоретично незалежний від реалізації мережі, зокрема, від мережевих протоколів транспортного рівня.

Програмні реалізації системи, як правило, підтримують один або два протоколи. Наприклад, система RPC розробки фірми Sun Microsystems підтримує передачу повідомлень з використанням протоколів TCP і UDP. Вибір того чи іншого протоколу залежить від вимог програми. Вибір протоколу UDP виправданий для додатків, що володіють наступними характеристиками:

Викликані процедури ідемпотентна
Розмір переданих аргументів і повертається результату менше розміру пакета UDP - 8 Кбайт.
Сервер забезпечує роботу з декількома сотнями клієнтів. Оскільки при роботі з протоколами TCP сервер змушений підтримувати з'єднання з кожним з активних клієнтів, це займає значну частину його ресурсів. Протокол UDP в цьому відношенні є менш ресурсномістких

З іншого боку, TCP забезпечує ефективну роботу додатків з наступними характеристиками:

Додатку потрібно надійний протокол передачі
Викликані процедури неідемпонентни
Розмір аргументів або повертається результату перевищує 8 Кбайт

Вибір протоколу зазвичай залишається за клієнтом, і система по-різному організовує формування і передачу повідомлень. Так, при використанні протоколу TCP, для якого передаються дані представляють собою потік байтів, необхідно відокремити повідомлення один від одного. Для цього наприклад, застосовується протокол маркування записів, описаний в RFC1057 "RPC: Remote Procedure Call Protocol specification version 2", при якому на початку кожного повідомлення поміщається 32-розрядний ціле число, яке визначає розмір повідомлення в байтах.

По-різному йде справа і з семантикою виклику. Наприклад, якщо RPC виконується з низьким рівнем транспортного протоколу (UDP), система виконує повторну передачу повідомлення через короткі проміжки часу (тайм-аути). Якщо додаток-клієнт не отримує відгук, то з упевненістю можна сказати, що процедура була виконана нуль або більше число разів. Якщо відгук був отриманий, додаток може зробити висновок, що процедура була виконана хоча б один раз. При використанні надійного транспортного протоколу (TCP) в разі отримання відгуку можна сказати, що процедура була виконана один раз. Якщо ж відгук ми отримали, безумовно сказати, що процедура виконано не було, нельзя3.

Як це працює?

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

Як приклад розглянемо RPC фірми Sun Microsystems. Система складається з трьох основних частин:

rpcgen (1) - RPC-компілятор, який на підставі опису інтерфейсу віддаленої процедури генерує заглушки клієнта і сервера у вигляді програм на мові С.
Бібліотека XDR (eXternal Data Representation), яка містить функції для перетворення різних типів даних в машинно-незалежний вид, що дозволяє проводити обмін інформацією між різнорідними системами.
Бібліотека модулів, що забезпечують роботу системи в цілому.

Розглянемо приклад найпростішого розподіленого додатка для ведення журналу подій. Клієнт при запуску викликає віддалену процедуру запису повідомлення в файл журналу віддаленого комп'ютера.

Для цього доведеться створити як мінімум три файли: специфікацію інтерфейсів віддалених процедур log.x (на мові опису інтерфейсу), власне текст віддалених процедур log.c і текст головний програми клієнта main () - client.c (на мові С).

Компілятор rpcgen (l) на підставі специфікації log.x створює три файли: текст заглушок клієнта і сервера на мові С (log clnt.c і log svc.c) і файл описів log.h, який використовується обома заглушками.

Отже, розглянемо вихідні тексти програм.

У цьому файлі вказуються реєстраційні установки для віддаленої процедури - номера програми, версії і процедури, а також визначається інтерфейс виклику - вхідні аргументи і повертаються значення. Таким чином, визначено процедуру RLOG, як аргумент приймає рядок (яка буде записана в журнал), а повертається значення стандартно вказує на успішне або невдале виконання замовленої операції.

program LOG_PROG ( version LOG_VER ( int RLOG (string) \u003d 1; ) \u003d 1; ) \u003d 0х31234567;

Компілятор rpcgen (l) створює файл заголовків log.h, де, зокрема, визначено процедури:

Розглянемо цей файл уважно. Компілятор транслює ім'я RLOG певне в файлі опису інтерфейсу, в rlog_1, замінюючи прописні символи на рядкові і додаючи номер версії програми з підкресленням. Тип значення, що повертається змінився з int на int *. Таке правило - RPC дозволяє передавати і отримувати тільки адреси оголошених при описі інтерфейсу параметрів. Це ж правило стосується і переданої в якості аргументу рядка. Хоча з файлу print.h це не слід, насправді в якості аргументу функції rlog_l () також передається адреса рядка.

Крім файлу заголовків компілятор rpcgen (l) створює модулі заглушки клієнта і заглушки сервера. По суті, в тексті цих файлів укладено весь код віддаленого виклику.

Заглушка серверу є головний програмою, обробній все мережеве взаємодія з клієнтом (точніше, з його заглушкою). Для виконання операції заглушка сервера виробляє локальний виклик функції, текст якої необхідно написати:

Заглушка клієнта приймає аргумент, який передається віддаленої процедури, робить необхідні перетворення, формує запит на сервер portmap (1M), обмінюється даними з сервером віддаленої процедури і, нарешті, передає повертається значення клієнту. Для клієнта виклик віддаленої процедури зводиться до виклику заглушки і нічим не відрізняється від звичайного локального виклику.

client.c

#include #include "Log.h" main(int argc, char * Argv) (CLIENT * cl; char * Server, * mystring, * clnttime; time_t bintime; int * Result; if (Argc! \u003d 2) (fprintf (stderr, "Формат виклику:% s Адрес_хоста \\ n", argv); exit (1);) server \u003d argv; / * Отримаємо дескриптор клієнта. У разі невдачі - повідомимо про неможливість встановлення зв'язку з сервером * / if ((З1 \u003d clnt_create (server, LOG_PROG, LOG_VER, "udp")) \u003d\u003d NULL) (clnt_pcreateerror (server); exit (2);) / * Виділимо буфер для рядка * / mystring \u003d ( char *) Malloc (100); / * Визначимо час події * / bintime \u003d time ((time_t *) NULL); clnttime \u003d ctime (& bintime); sprintf (mystring, "% s - Клієнт запущений", clnttime); / * Передамо повідомлення для журналу - час початку роботи клієнта. У разі невдачі - повідомимо про помилку * / if ((Result \u003d rlog_l (& mystring, cl)) \u003d\u003d NULL) (Fprintf (stderr, "error2 \\ n"); clnt_perror (cl, server); exit (3);) / * B разі невдачі на віддаленому комп'ютері повідомимо про помилку * / if (* Result! \u003d 0) fprintf (stderr, "Не можу записати журнал \\ n"); / * 0свободім дескриптор * / cint destroy (cl); exit (0); )

Заглушка клієнта log_clnt.c компілюється з модулем client.c для отримання виконуваної програми клієнта.

Тепер на деякому хості server.nowhere.ru необхідно запустити серверний процес:

$ logger

Після чого при запуску клієнта rlog на іншій машині сервер додасть відповідний запис в файл журналу.

Схема роботи RPC в цьому випадку приведена на рис. 1. Модулі взаємодіють наступним чином:

Коли запускається серверний процес, він створює сокет UDP і пов'язує будь-який локальний порт з цим сокетом. Далі сервер викликає бібліотечну функцію svc_register (3N) для реєстрації номерів програми і її версії. Для цього функція звертається до процесу portmap (IM) і передає необхідні значення. Сервер portmap (IM) зазвичай запускається при ініціалізації системи і зв'язується з деяких загальновідомих портом. Тепер portmap (3N) знає номер порту для нашої програми і версії. Сервер ж очікує отримання запиту. Зауважимо, що всі описані дії виробляються заглушкою сервера, створеної компілятором rpcgen (IM).
Коли запускається програма rlog, перше, що вона робить, - викликає бібліотечну функцію clnt_create (3N), вказуючи їй адреса віддаленої системи, номера програми і версії, а також транспортний протокол. Функція направляє запит до сервера portmap (IM) віддаленої системи server.nowhere.m і отримує номер віддаленого порту для сервера журналу.
Клієнт викликає процедуру rlog_1 (), визначену в заглушці клієнта, і передає управління заглушці. Та, в свою чергу, формує запит (перетворюючи аргументи на формат XDR) у вигляді пакета UDP і направляє його на віддалений порт, отриманий від сервера portmap (IM). Потім вона деякий час очікує відгуку і в разі неотримання повторно відправляє запит. За сприятливих обставин запит приймається сервером logger (модулем заглушки сервера). Заглушка визначає, яка саме функція була викликана (за номером процедури), і викликає функцію rlog_1 () модуля log.c. Після повернення управління назад в заглушку остання перетворює повернене функцією rlog_1 () значення в формат XDR, і формує відгук також у вигляді пакету UDP. Після отримання відгуку заглушка клієнта витягує повернене значення, перетворює його і повертає в головний програму клієнта

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

Характерними рисами виклику локальних процедур є:

Базові операції RPC

Count \u003d read (fd, buf, nbytes);

де fd - ціле число,
buf - масив символів,
nbytes - ціле число.

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

Мал. 3.2. Remote Procedure Call

Мал. 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. Специфікація сервера RPC

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

Семантика RPC у разі відмов

В ідеалі RPC повинен функціонувати правильно і в разі відмов. Розглянемо наступні класи відмов:

Java RMI як тип віддаленого виклику процедур, незалежного від мережі, основні кроки роботи з ним і призначення. Порівняння розподілених і нерозподілених Java програм. Рівні архітектури, заглушки і скелета, віддалених посилань і транспорту Java RMI.

Попередня компіляція SQL-запитів за місцем виконання. Використання інструкції prepareStatement. Використання синтаксису визначення виклику для отримання значення, що повертається процедурою або функцією. Створення інструкції на вибірку за запитом.

Призначення і схема роботи. Склад і установка. Специфікація процедур пакету http.

Процедури і функції можна визначити як замкнуті програмні одиниці, що реалізують деякий алгоритм. Фактично процедура або функція - це майже програма.

Автоматизована настройка TCP / IP, динамічна настройка конфігурації з застосуванням BOOTP. IP-адреси запитів / відповідей, втрата і формат повідомлення, фази ВООТP. Протокол DHCP як розширення протоколу ВООТP. Розподіл і призначення IP-адрес.

З поняттям рекурсії ми вже зустрічалися: рекурентні співвідношення досить часто зустрічаються в математичних виразах. Рекурсія в визначенні полягає в тому, що визначається поняття визначається через саме це поняття.

1. Введення 2 2. Огляд COM-технології 2 2.1. Склад COM-об'єкта 3 2.2. Інтерфейси 4 2.3. Властивості COM-об'єктів 6 2.4. COM-сервери 6 2.5. Механізм маршаллінг 7

Вивчення сутності, принципу роботи та основного призначення віддалених баз даних. Модель віддаленого управління даними (модель файлового сервера). Типи паралелізму. Тригер - механізм відстеження спеціальних подій, які пов'язані зі станом БД.

Пакети моделі метамоделі, фактів і безпеки. Концептуальна модель клієнта. Приклад функціонування розподіленої архітектури. Складність реалізації.

Поняття Dll. Згадаймо процес програмування в DOS. Перетворення вихідного тексту в машинний код включав в себе 2 процесу: компіляцію і лінковку. Під час компонування в код програми містилися не тільки оголошення функцій і процедур, а й їх повний код.

Функції для роботи з протоколом TCP / IP, Socket, Bind, listen і accept. Файловий дескриптор. Комунікаційні процеси. Прийом даних. Читання з сокета. Запис в сокет. Закриття сокета. Текст програми, що створює Web-сервер в операційній системі QNX.

Доступ користувачів мережі до електронних повідомлень, Що зберігаються на сервері. Опис програми, аутентифікація проста, APOP і AUTH-аутентифікація. Реалізація функцій, керівництво користувача, алгоритми функціонування програми, графічний інтерфейс.

Принцип роботи основних операторів мови програмування Turbo-Paskal: оператор присвоювання, вибору Case, безумовного переходу, циклу, уловний, складовою. Формальний опис і виклик функції і процедури. Вимоги до списку фактичних параметрів.

Принцип роботи та призначення сервлетів Java, їх значення в підвищенні функціональності Web-серверів і поліпшення їх програмування, переваги і недоліки використання. Способи виклику сервлетов з браузера і сторінки. Запис і читання атрибутів сесії.

Архітектура ОС Windows NT. Структура ОС на базі мікроядра. Захищені підсистеми Windows NT.

Базові примітиви передачі повідомлень в розподілених системах. Способи адресації. Блокують і не блокують примітиви. Буферизованих і не буферизованих примітиви.

Сервер додатків. Клієнтська частина.

Це два роки тому AJAX був у дивину (та й самого слова AJAX тоді ще не вигадали). Тепер веб-додатки, сторінки яких оновлювалися на льоту, в порядку речей. Навіть навпаки: без AJAX важко уявити собі деякі сервіси.

Синтаксис опису і виклику процедури. Параметри. Приклад опису і виклику процедури. Види параметрів. Програма.