Розподілені обчислення на основі стека протоколів TCP / IP, Локальні мережі, статті

Андрій Лапоухов

Розглянемо особливості організації розподілених обчислень. Від централізованих вони відрізняються наявністю зв’язку між процесами. Зв’язки між централізованими процесами припускають наявність поділюваної пам’яті. Класичний приклад створення буферів читання / запису при зверненні до масиву даних.

Основою взаємодії розподілених обчислень служить посилка і прийом повідомлень. Уже на двох програмних примітивах (посилка і прийом) можна побудувати досить складні засоби мережевих комунікацій, наприклад, програмні системи в архітектурі Клієнт / Сервер чи виклик віддалених процедур (Remote Procedure Call). Розглянемо ці кошти більш докладно. Засоби віддаленого виклику процедур призначені для полегшення створення розподілених обчислень. Реалізація віддалених викликів істотно складніше реалізації викликів локальних процедур. Почнемо з того, що викликає і викликається процедури виконуються на різних машинах. Вони мають різні адресні простори і це створює додаткові проблеми при передачі параметрів і результатів, особливо для машин різних класів. Програми RPC не можуть розраховувати на поділювану пам’ять, отже, неможливо передати покажчик на стек, значення параметрів повинні бути надіслані з одного комп’ютера на інший. Інша відмінна особливість RPC – використання будь-якої системи зв’язку між комп’ютерами. Однак цей зв’язок дуже прозора, тобто програміст, який проектує RPC-орієнтоване додаток, не займається низькорівневими протоколами. У реалізації RPC беруть участь, як мінімум, два процесу і при аварійному завершенні одного з них інший в очікуванні відповіді буде крутитися вхолосту.
Питання зв’язку процесів (за допомогою передачі параметрів або віддалених викликів) тісно пов’язані з питаннями синхронізації процесів. Синхронізація необхідна процесам для організації спільно використовуваних ресурсів. Розглянемо основні типи алгоритмів, які можуть бути використані в розподілених системах:
1. Централізований алгоритм. Один з процесів вибирається в якості координатора. Коли-небудь процес хоче увійти в критичну секцію, він посилає запит координатору і чекає відповіді. Якщо в цей момент жоден з процесів не знаходиться в критичній секції, то координатор надсилає відповідь з дозволом. Якщо ж певний процес виконує критичну секцію, відповідь не надсилається. Він ставиться в чергу і після звільнення критичної секції йому надсилається відповідь-дозвіл.
2. Розподілений алгоритм. Якщо процес хоче увійти в критичну секцію, він формує повідомлення, що містить ім’я потрібної йому критичної секції, номер процесу та поточне значення часу. Це повідомлення розсилається всім іншим процесам. Можливі три варіанти: приймає процес знаходиться не в критичній секції – надсилається дозвіл; процес знаходиться в критичній секції – він не відправляє ніякого відповіді і ставить запит у чергу; процес хоче увійти в критичну секцію, але ще не зробив цього – він порівнює тимчасову позначку надійшло повідомлення із значенням часу, який міститься в його власному запиті, розісланому всім іншим процесам. Якщо час надійшов до нього повідомлення менше, тобто його власний запит виник пізніше, він посилає повідомлення-дозвіл. В іншому випадку він не посилає нічого і ставить надійшло повідомлення в чергу. Процес може увійти в критичну секцію тільки в тому випадку, якщо він отримав відповідь повідомлення-дозволи від всіх інших процесів. Їли процес залишає критичну секцію, він посилає дозвіл всіх процесів зі своєї черги і очищає її.
3. Алгоритм Token Ring. Всі процеси в системі утворюють логічне кільце, тобто кожний процес знає номер своєї позиції в кільці, а також номер найближчого до нього процесу. Коли кільце ініціалізується, процесу під номером 0 передається маркер (token). Маркер циркулює по кільцю. Він переходить від процесу n до процесу n +1. Коли процес отримує маркер, він аналізує ситуацію, не треба йому увійти в критичну секцію. Якщо так, він залишає маркер у себе і починає виконання критичного ділянки програми, після виходу з нього він передає маркер далі по кільцю. Якщо ж процес не зацікавлений у входженні в критичну секцію, він відразу ж передає маркер далі по кільцю. Тобто, якщо жоден з процесів не зацікавлений у входженні в критичну секцію, маркер просто циркулює по кільцю.
Порівняємо ці три алгоритму. Централізований алгоритм є найбільш простим і ефективним. При його використанні потрібно тільки три повідомлення. При використанні розподіленого алгоритму для виконання однієї критичної секції потрібно послати (n-1) повідомлень-запитів (де n-число процесів), по одному на кожен процес, і отримати (n-1) дозволів, тобто все необхідно 2 (n-1) повідомлень. В алгоритмі Token Ring число повідомлень змінно: від одного, якщо кожен процес входить в критичну секцію, до нескінченно великого числа при циркуляції маркера по кільцю. На жаль, алгоритми такого типу погано захищені від відмов.
Наведемо основні риси сучасного RPC-протоколу:
‰ машинно-незалежний інструментарій, що дозволяє створювати додатки, здатні обмінюватися даними з додатками, запущеними на різних типах ОС;
‰ опрацьована технологія створення Клієнт / серверних додатків;
‰ компілятор RPC-протоколу, який дозволяє приховати низкоуровневую реалізацію міжмережевого обміну даними;
‰ аутентифікація, що дає можливість будувати розподілені додатки, що забезпечують авторизований доступ;
‰ набір високорівневих бібліотек, що дозволяє досить легко працювати з такими мережевими об’єктами, як користувачі (users), пристрої і комп’ютери, підключені до мережі (hosts), поштові ящики (mailboxes).

Історія та стандарти розподілених обчислень

Історія створення RPC своїм корінням сягає в далекі 80-і роки. Основою цієї технології вважаються “рекомендації з мережних обчислень” фірми Apollo Computers, відомі під абревіатурою NCA (Network Computing Architecture).
Сучасний світ розподілених обчислень розбитий на два стандарти: з одного берега знаходиться ONC (Open Network Computing), з іншого – NCS (Network Computing Systems). У таборі ONC знаходяться такі гіганти, як Sun, AT & T, Novell і Netwise, до прихильникам NCS можна віднести HP, IBM, DEC, Microsoft (рис.1).
Одним з плюсів ONC є відкритість цієї системи: вихідні коди доступні широкій громадськості. NCS і ONC загалом дуже схожі один на одного. Обидва ці стандарту входять до складу різних операційних систем та інструментальних засобів. NCS була створена як частина великої концепції розподілених обчислень, розробленої двома компаніями Apollo Computers і HP. NCS – закінчена технологія, готова до застосування. Вона є свого роду комбінацією двох продуктів – NCS / NCK (Network Computing Kernel) і NCS / NIDL (Network Interface Description Language). NCK – це бібліотека-виконання (run-time), яка включає підтримку RPC і мережевий менеджер ресурсів з аутентифікацією, званий Location Broker. З цієї специфікації низькорівневі RPC API-функції працюють через свій формат даних NDR (Network Data Representation). Інший компонент NCS – NIDL являє собою набір інструментів для побудови розподілених додатків, що включає компілятор протоколу (тобто компілятор, який замінює локальні виклики на RPC виклики). Він транслює дані формату мови Сі в NCA-дані і забезпечує спільну роботу NCK з клієнтськими і серверними частинами програми. Трохи про Location Broker: він розділений на два інтерфейси – локальний і глобальний (LLB і GLB). LLB видає інформацію про ресурси конкретної ПЕОМ, на якій він встановлений. GLB забезпечує інформацією про мережу в цілому. Ці брокери отримують інформацію про мережеві ресурси безпосередньо з транспортного протоколу NCS RPC, тобто клієнт завжди зможе дізнатися, чи доступний сервер. Також брокер може виконувати аутентифікаційні завдання, перевіряючи, використовує Чи програмне забезпечення клієнта Ліцензійну угоду NCS RPC. Набори NCS / NCK і NCS / NIDL підтримуються такими операційними системами, як HP-UX, SunOS, VAX / VMS і VAX / ULTRIX.
ONC. Батьком концепції ONC є компанія Sun. Концепція включає такі рівні: XDR (External Data Representation) – представлення даних для транспортного протоколу, якими обмінюються Клієнт і Сервер; NIS (Network Information Server) – який дуже схожий на Location Broker з NCS; RPCGEN – компілятор викликів функцій у стилі мови Сі на міжмережеві дзвінки RPC. Компілятор протоколу – один з важливих інструментів побудови розподілених обчислень. Дві технології – NCS і ONC включають компілятори протоколів: NIDL і RPCGEN відповідно. Обидва використовують синтаксис, дуже схожий на синтаксис мови Сі з директивами для препроцесора і структурним описом блоків. NCS також підтримує і Паскалеподобний синтаксис. ONC може включати мережеву файлову систему NFS (Network File Systems) з автоматичним підключенням мережевих томів (дисків) в файлову систему локальної ПЕОМ, блокуванням файлів, розмежуванням прав доступу і моніторингом роботи файлової системи.

RPC – мовна модель

Не так давно програми представляли собою монолітні блоки коду, які були розбиті на функції, і виклики здійснювалися в межах адресного простору, відведеного програмою. Шляхом створення завантажувальних бібліотек можна було частина програмного коду оформити в таку бібліотеку і при необхідності завантажувати / вивантажувати її в ОЗУ ПЕОМ (рис. 2).
RPC надає інший рівень програмування: програмний код можна викликати і на віддаленій ПЕОМ, підключеної якимось чином до мережі. Розглянемо, як відбувається RPC виклик. Програміст створює клієнтську і серверну частину програми (як серверної частини може виступати системний сервіс, що входить в поставку відповідних операційних систем). Клієнтська і серверна частини запускаються на різних ПЕОМ, з’єднаних в мережу. Втім, це можна промоделювати і на одній ПЕОМ. Клієнтська частина викликає код, розташований на ПЕОМ з серверною частиною програми. Функціональний виклик (1) перехоплює так звана заглушка (Program Stub), яка перенаправляє локальний виклик в RPC-бібліотеку часу-виконання (2), в ній відбувається перетворення даних під існуючий транспортний протокол (3). Дані та службова інформація переносяться по мережі (4), декодуються в RPC-бібліотеці часу-виконання, розташованої на ПЕОМ з серверною частиною (5), і через заглушку потрапляють на серверну частину програми. У серверній ПЕОМ запускається відповідний запит програмний код і результати його роботи за вже відомою схемою передаються в клієнтську частину (рис. 3).
Бібліотеки часу-виконання RPC-протоколу багатьох фірм можуть подлінковиваться до додатка, і при його постачанні немає необхідності в перенесенні цих бібліотек.
RPC може працювати і локально. При локальному виклик весь процес передачі параметрів відбувається в одному адресному просторі. Етапи створення RPC-додатки відповідно до цієї моделі наведено на рис. 4.
При побудові RPC-орієнтованих програм необхідно вибирати транспортний протокол, в який будуть інкапсулюватися RPC-виклики. Розглянемо основні переваги та недоліки двох базових транспортів стека протоколів TPC / IP: TCР (Transmission Control Protocol) і UDP (Usr Datagram Protocol). Протокол UDP (RFC-768) надає прикладним процесам транспортні послуги, він забезпечує доставку дейтограмм, не вимагаючи підтвердження їх одержання. Він не вимагає “установки з’єднання”. До IP-пакету на рівні UDP додається порт відправника, порт одержувача і довжина UDP-дейтограмми плюс контрольна сума для забезпечення цілісності даних. При доставці IP-дейтограмми потрібно IP-адресу машини-приймача, в разі UDP-протоколу необхідні ще й номери портів. Порт – це логічний канал для установки з’єднання. UDP-порти нумеруються, починаючи з нуля. Прикладний процес, що надає послуги, очікує повідомлення, направленого в порт, спеціально виділений для цих послуг. Номери портів 0-255 стандартизовані і їх в прикладних процесах використовувати не рекомендується, але і в інтервалі 255-1023 багато порти вже зайняті, тому перш ніж використовувати будь-порт рекомендується заглянути в RFC-1700. Більшість додатків TCP / IP використовують номери портів в діапазоні 1024-5000. Наприклад: 21 – FTP (протокол передачі файлів), 23 – TELNET (підключення терміналів), 25 – SMTP (протокол передачі поштових повідомлень).
Протокол TCP (RFC-793, 1323) на відміну від UDP здійснює доставку дейтограмм, званих сегментами, у вигляді байтових потоків з встановленим з’єднанням. Протокол TCP застосовується в тому випадку, коли потрібно гарантована доставка повідомлень. Він використовує контрольні суми пакетів для перевірки їх цілісності та звільняє прикладні процеси від необхідних тайм-аутів і повторних передач для забезпечення надійності. Але TCP дуже “важкий” протокол. Для посилки одного байта інформації потрібно послати 41-байтовий пакет (20 байт IP-заголовка, 20 байт TCP-заголовка плюс байт даних). Хоча TCP зазвичай намагається поєднати посилку інформації в “одному напрямку”, очікування може досягати 200 мс (максимум 500 мс). TCP – протокол з дуже низьким ККД.
Більш докладно з RPC можна ознайомитися в наступних документах:

RFC-1050 RPC: Remote Procedure Call Protocol specification. Sun Microsystems, 1988. (Status: HISTORIC)

RFC-1057 RPC: Remote Procedure Call Protocol specification: Version 2. Sun Microsystems, 1988. (Status: INFORMATIONAL)

RFC-1831 RPC: Remote Procedure Call Protocol Specification Version 2, 1995. (Status: PROPOSED STANDARD)

RFC-1833 Binding Protocols for ONC RPC Version 2, 1995. (Status: PROPOSED STANDARD)

RFC-2695 Authentication Mechanisms for ONC RPC, 1999. (Status: INFORMATIONAL)

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*