Управління розподіленими ресурсами Базові примітиви передачі повідомлень в розподілених системах

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

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

Незважаючи на концептуальну простоту цих системних викликів - НАДІСЛАТИ і ОТРИМАТИ - існують різні варіанти їх реалізації, від правильного вибору яких залежить ефективність роботи мережі. Зокрема, ефективність комунікацій в мережі залежить від способу завдання адреси, від того, чи є системний виклик блокуючим або неблокірующім, які обрані способи буферизації повідомлень і наскільки надійним є протокол обміну повідомленнями. Способи адресації

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

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

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

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

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

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

Примітиви бувають блокуючими і неблокірующімі, іноді вони називаються відповідно синхронними і асинхронними. При використанні блокуючого примітиву, процес, який видав запит на його виконання, призупиняється до повного завершення примітиву. Наприклад, виклик примітиву ОТРИМАТИ призупиняє викликає процес до отримання повідомлення.

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

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

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

Питанням, тісно пов'язаним із блокуючими і неблокірующімі викликами, є питання тайм-аутів. В системі з блокуючим викликом НАДІСЛАТИ за відсутності відповіді викликає процес може заблокуватися назавжди. Для запобігання такій ситуації в деяких системах викликає процес може задати тимчасової інтервал, протягом якого він очікує відповіді. Якщо за цей час повідомлення не надходить, виклик НАДІСЛАТИ завершується з кодом помилки. Буферізуемие і небуферізуемие примітиви

Примітиви, які були описані, є небуферізуемимі примітивами. Це означає, що виклик ОТРИМАТИ повідомляє ядру машини, на якій він виконується, адреса буфера, в який слід помістити що триває для нього повідомлення.

Ця схема працює чудово за умови, що одержувач виконує виклик ОТРИМАТИ раніше, ніж відправник виконує виклик НАДІСЛАТИ. Виклик ОТРИМАТИ повідомляє ядру машини, на якій виконується, за якою адресою повинно надійти очікуване повідомлення, і в яку область пам'яті необхідно його помістити. Проблема виникає тоді, коли виклик НАДІСЛАТИ зроблений раніше дзвінка ОТРИМАТИ. Яким чином зможе дізнатися ядро на машині одержувача, якому процесу адресовано знову надійшло повідомлення, якщо їх декілька? І як воно знатиме, де його скопіювати?

Один з варіантів - просто відключити повідомлення, дозволити відправнику взяти тайм-аут і сподіватися, що одержувач все-таки виконає виклик ОТРИМАТИ перед повторною повідомлення. Цей підхід не складний в реалізації, але, на жаль, відправник (або швидше ядро його машини) може зробити кілька таких безуспішних спроб. Ще гірше те, що після досить великої кількості безуспішних спроб ядро відправника може зробити неправильний висновок про аварію на машині одержувача або про неправильність використаного адреси.

Другий підхід до цієї проблеми полягає в тому, щоб зберігати хоча б деякий час, що надходять повідомлення в ядрі одержувача на той випадок, що незабаром буде виконано відповідний виклик ОТРИМАТИ. Кожного разу, коли надходить таке "неочікуваний" повідомлення, включається таймер. Якщо заданий інтервал часу минає раніше, ніж відбувається відповідний виклик ОТРИМАТИ, то повідомлення втрачається.

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

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

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

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

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

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