Передача параметрів за посиланнями.

Покажчик має сенс тільки в адресному просторі того процесу, в якому він використовується. Повертаючись до прикладу з процедурою read, другий параметр (адреса буфера) для клієнта може бути рівний наприклад 1000. Але якщо просто подати на сервер число 1000 і очікувати, то число 100 цілком може припасти на середину тексту програми.

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

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

Розширені моделі RPC.

Дистанційні виклики процедур стали фактичним стандартом для зв'язку в розподілених системах. Популярність цієї моделі пояснюється її простотою.

Входи.

Базова модель RPC припускає, що викликаюча і викликаєма системи можуть зв'язуватися одна з одною після обміну повідомленнями по мережі. В загальному випадку це припущення правдиве. Однак розглянемо варіант, коли клієнт і сервер встановлені на одній машині. У стандартному випадку ми повинні використовувати засоби локальної міжпроцесорної взаємодії (Inter Process Communication, IPC), які базова операційна система надає процесам, запущеним на одній машині.

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

Як компроміс деякі операційні систем надають процесам, розміщеним на одній машині, еквівалент RPC під назвою входів (doors). Вхід - це узагальнене ім’я процедур, існуючих в адресному просторі сервера, які можуть викликатися процесами, розміщеної на одній з сервером машині.

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

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

Рис.11.Принципи використання входів в якості механізму IPC