Єдиним по-справжньому важливою відмінністю розподілених систем від централізованих є межпроцессное взаємозв'язок. У централізованих системах зв'язок між процесами, як правило, передбачає наявність пам'яті, що розділяється. Типовий приклад - проблема "постачальник-споживач", в цьому випадку один процес пише в розділяється буфер, а інший - читає з нього. Навіть найбільш проста форма синхронізації - семафор - вимагає, щоб хоча б одне слово (змінна самого семафора) було розділяються. У розподілених системах немає якої б то не було пам'яті, що розділяється, таким чином вся природа межпроцессное комунікацій повинна бути продумана заново.
Основою цієї взаємодії може служити тільки передача по мережі повідомлень. У самому простому випадку системні засоби забезпечення зв'язку можуть бути зведені до двох основних системних викликів (примітивам), один - для відправлення повідомлення, інший - для отримання повідомлення. У подальшому на їх базі можуть бути побудовані більш потужні засоби мережевих комунікацій, такі як розподілена файлова система або виклик віддалених процедур, які, у свою чергу, також можуть служити основою для побудови інших мережевих сервісів.
Незважаючи на концептуальну простоту цих системних викликів - ПОСЛАТИ та ОТРИМАТИ - існують різні варіанти їх реалізації, від правильного вибору яких залежить ефективність роботи мережі. Зокрема, ефективність комунікацій у мережі залежить від способу завдання адреси, від того, чи є системний виклик блокуючим або неблокуючим, які обрані способи буферизації повідомлень і наскільки надійним є протокол обміну повідомленнями.
Способи адресаціїДля того, щоб послати повідомлення, необхідно вказати адресу одержувача. У дуже простий мережі адреса може задаватися у вигляді константи, але в більш складних мережах потрібен і більш витончений спосіб адресації.
Одним з варіантів адресації на верхньому рівні є використання фізичних адрес мережевих адаптерів. Якщо в одержує комп'ютері виконується тільки один процес, то ядро буде знати, що робити з надійшли повідомленням - передати його цьому процесу. Однак, якщо на машині виконується кілька процесів, то ядра не відомо, якому з них призначено повідомлення, тому використання мережевої адреси адаптера в якості адреси одержувача призводить до дуже серйозного обмеження - на кожній машині повинен виконуватися тільки один процес.
Альтернативна адресна система використовує імена призначення, що складаються з двох частин, що визначають номер машини і номер процесу. Однак адресація типу "машина-процес" далека від ідеалу, зокрема, вона не гнучка й не прозора, тому що користувач повинен явно задавати адресу машини-одержувача. У цьому випадку, якщо в один прекрасний день машина, на якій працює сервер, відмовляє, то програма, в якій жорстко використовується адресу сервера, не зможе працювати з іншим сервером, встановленому на іншій машині.
Іншим варіантом могло б бути призначення кожному процесу унікального адреси, який ніяк не пов'язаний з адресою машини. Одним із способів досягнення цієї мети є використання централізованого механізму розподілу адрес процесів, який працює просто, як лічильник. При отриманні запиту на виділення адреси він просто повертає поточне значення лічильника, а потім нарощує його на одиницю. Недоліком цієї схеми є те, що централізовані компоненти, подібні до цього, не забезпечують в достатній мірі розширюваність систем. Ще один метод призначення процесам унікальних ідентифікаторів полягає у вирішенні кожному процесу вибору свого власного ідентифікатора з дуже великого адресного простору, такого як простір 64-х бітних цілих чисел. Імовірність вибору одного і того ж числа двома процесами є нікчемним, а система добре розширюється. Однак тут є одна проблема: як процес-відправник може дізнатися номер машини процесу-одержувача. У мережі, яка підтримує широкомовний режим (тобто в ній передбачено таку адресу, який приймають всі мережеві адаптери), відправник може широкомовно передати спеціальний пакет, який містить ідентифікатор процесу призначення. Всі ядра отримають ці повідомлення, перевірять адресу процесу і, якщо він збігається з ідентифікатором одного з процесів цієї машини, пошлють відповідь "Я тут", що містить мережеву адресу машини.
Хоча ця схема і прозора, але широкомовні повідомлення перевантажують систему. Такий перевантаження можна уникнути, виділивши в мережі спеціальну машину для відображення високорівневих символьних імен. При застосуванні такої системи процеси адресуються за допомогою символьних рядків, і в програми вставляються ці рядки, а не номери машин або процесів. Кожного разу перед першою спробою зв'язатися, процес повинен надіслати запит спеціальному отображающему процесу, звичайно званому сервером імен, запитуючи номер машини, на якій працює процес-одержувач.
Зовсім інший підхід - це використання спеціальної апаратури. Нехай процеси вибирають свої адреси випадково, а конструкція мережевих адаптерів дозволяє зберігати ці адреси. Тепер адреси процесів не виявляються шляхом широкомовної передачі, а безпосередньо зазначаються в кадрах, замінюючи там адреси мережевих адаптерів.
Блокуючі і неблокуючим примітивиПримітиви бувають блокуючими і неблокуючим, іноді вони називаються відповідно синхронними і асинхронними. При використанні блокуючого примітиву, процес, який видав запит на його виконання, призупиняється до повного завершення примітиву. Наприклад, виклик примітиву ОТРИМАТИ призупиняє викликаючий процес отримання повідомлення.
При використанні неблокуючим примітиву управління повертається зухвалому процесу негайно, ще до того, як необхідна робота буде виконана. Перевагою цієї схеми є паралельне виконання викликає процесу та процесу передачі повідомлення. Зазвичай в ОС є один з двох видів примітивів і дуже рідко - обидва. Однак виграш в продуктивності при використанні неблокуючим примітивів компенсується серйозним недоліком: відправник не може модифікувати буфер повідомлення, поки повідомлення не відправлено, а дізнатися, надіслано повідомлення, відправник не може. Звідси складності у побудові програм, які передають послідовність повідомлень за допомогою неблокуючим примітивів.
Є два можливі виходи. Перше рішення - це змусити ядро копіювати повідомлення в свій внутрішній буфер, а потім дозволити процесу продовжити виконання. З точки зору процесу ця схема нічим не відрізняється від схеми блокуючого виклику: як тільки процес знову отримує управління, він може повторно використовувати буфер.
Друге рішення полягає в перериванні процесу-відправника після відправки повідомлення, щоб поінформувати його, що буфер знову доступний. Тут не потрібно копіювання, що економить час, але переривання користувацького рівня робить програмування заплутаним, складним, може призвести до виникнення гонок.
Питанням, тісно пов'язаним із блокуючими і неблокуючим викликами, є питання тайм-аутів. У системі з блокуючим викликом ПОСЛАТИ при відсутності відповіді викликає процес може блокуватися назавжди. Для запобігання такій ситуації в деяких системах викликає процес може задати часовий інтервал, протягом якого він чекає на відповідь. Якщо за цей час повідомлення не надходить, виклик ПОСЛАТИ завершується з кодом помилки.
Буферізуемие і небуферізуемие примітивиПримітиви, які були описані, є небуферізуемимі примітивами. Це означає, що виклик ОТРИМАТИ повідомляє ядро машини, на якій він виконується, адреса буфера, в який слід помістити перебуває для нього повідомлення.
Ця схема працює чудово за умови, що одержувач виконує виклик ОТРИМАТИ раніше, ніж відправник виконує виклик ПОСЛАТИ. Виклик ОТРИМАТИ повідомляє ядро машини, на якій виконується, за якою адресою має надійти очікуване повідомлення, і в яку область пам'яті необхідно його помістити. Проблема виникає тоді, коли виклик ПОСЛАТИ зроблений раніше виклику ОТРИМАТИ. Яким чином зможе дізнатися ядро на одержувача, якому процесу адресовано знову надійшло повідомлення, якщо їх декілька? І як вона дізналася, куди його скопіювати?
Один з варіантів - просто відмовитися від повідомлення, дозволити відправнику взяти тайм-аут і сподіватися, що одержувач все-таки виконає виклик ОТРИМАТИ перед повторною повідомлення. Цей підхід не складний в реалізації, але, на жаль, відправник (або скоріше ядро його машини) може зробити кілька таких безуспішних спроб. Ще гірше те, що після досить великого числа безуспішних спроб ядро відправника може зробити неправильний висновок про аварію на машині одержувача або про неправильність використаного адреси.
Другий підхід до цієї проблеми полягає в тому, щоб зберігати хоча б деякий час, що надходять повідомлення в ядрі одержувача на той випадок, що незабаром буде виконаний відповідний виклик ОТРИМАТИ. Кожного разу, коли надходить таке "несподіване" повідомлення, включається таймер. Якщо заданий часовий інтервал закінчується раніше, ніж відбувається відповідний виклик ОТРИМАТИ, то повідомлення втрачається.
Хоча цей метод і зменшує ймовірність втрати повідомлень, він породжує проблему зберігання і управління передчасно надійшли повідомленнями. Необхідні буфери, які слід десь розміщувати, звільняти, загалом, якими треба керувати. Концептуально простим способом управління буферами є визначення нової структури даних, званої поштовою скринькою.
Процес, який зацікавлений в отриманні повідомлень, звертається до ядра із запитом про створення для нього поштової скриньки і повідомляє адресу, за якою йому можуть надходити мережні пакети, після чого всі повідомлення з даними адресою будуть поміщені в його поштову скриньку. Такий спосіб часто називають буферізуемим примітивом.
Надійні і ненадійні примітивиРаніше передбачалося, що коли відправник посилає повідомлення, адресат його обов'язково отримує. Але реально повідомлення можуть втрачатися. Припустимо, що використовуються блокуючі примітиви. Коли відправник посилає повідомлення, то він припиняє свою роботу до тих пір, поки повідомлення не буде надіслано. Однак немає жодних гарантій, що після того, як він відновить свою роботу, повідомлення буде надіслано адресату.
Для вирішення цієї проблеми існує три підходи. Перший полягає в тому, що система не бере на себе жодних зобов'язань з приводу доставки повідомлень. Реалізація надійної взаємодії стає цілком турботою користувача.
Другий підхід полягає в тому, що ядро приймаючої машини посилає квитанцію-підтвердження ядру відправляє машини на кожне повідомлення. Посилає ядро розблокує користувача процес тільки після отримання цього підтвердження. Підтвердження передається від ядра до ядра. Ні відправник, ні одержувач його не бачать.
Третій підхід полягає у використанні відповіді в якості підтвердження в тих системах, в яких запит завжди супроводжується відповіддю. Відправник залишається заблокованим до отримання відповіді. Якщо відповіді немає занадто довго, то посилає ядро може переслати запит спеціальній службі запобігання втрати повідомлень.