2.1. Передача параметрів.

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

Передача параметрів по значенню.

Упаковка параметрів в повідомлення носить назву маршалінгу параметрів (parameter marshaling). В якості простішого прикладу розглянемо віддалену процедуру add (i. j), яка використовує два цілих параметра, i та j, і повертає в результат їх арифметичну суму. Виклик add ілюструється лівою частиною рис.10. Клієнтська заглушка витягує два її параметри і, як показано на малюнку упаковує їх в повідомлення.

Рис.10. Процес видалення обчислень з використанням RPC

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

Таким чином відбувається наступна процедура:

1. Клієнт викликає процедуру add.

2. Клієнтська заглушка будує повідомлення.

3. Повідомлення відправляється по мережі на сервер.

4. Операційна система сервера передає повідомлення серверній заглушці.

5. Серверна заглушка розпаковує повідомлення.

6. Серверна заглушка виконує локальний виклик процедури add.

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

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

Подібні проблеми можуть виявитися при передачі цілих чисел (знаковий або значущий старший біт) і чисел з плаваючою точкою. В добавок існує значно серйозніша проблема - в деяких машинах, таких як Pentium, байти нумеруються справа наліво, а в інших, наприклад Sun SPARC, - у зворотному напрямку.

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

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

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

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