Головна

Механізм виклику віддалених процедур - RPC | Принципи побудови протоколу. | Програмний інтерфейс високого рівня. | передача параметрів | client.c |

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

  1. II. Підберіть пари антонімів з даних слів і навчіться їх.
  2. VI Відповідальність сторін, що регулюють відносини на основі даних Правил
  3. А тепер я зроблю ось що. Я візьму кілька мінералів. Всього пару, щоб ви мали уявлення, а взагалі-то це відноситься до всіх мінералів без винятку.
  4. А). сформувати цілісне уявлення про руховому акті, засноване на розумінні його суті;
  5. А-аналіз анкетних даних
  6. А. Шопенгауер. До етики (Світ як воля і уявлення. - Т. 2. - М., 1993. - с. 579 - 616.

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

Більшість реалізацій системи 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.



семантика виклику | Як це працює?
© um.co.ua - учбові матеріали та реферати