ТЕМА 3: ПРОЦЕСИ Трофимчук І.М. Трофимчук І.М. ТМ-41м, ІТС ТМ-41м, ІТС

ЗМІСТ 3.1. Потоки виконання Клієнти Сервери Перенесення коду Програмні агенти Висновки.

3.1. ПОТОКИ ВИКОНАННЯ (ПВ) Процеси – будівельні блоки розподільчих систем. Подрібнення на процеси, яке здійснюється ОС, на базі яких будуються розподільчі системи, недостатньо. Наявність більш тонкого подрібнення у формі декількох потоків виконання (threads) на процес спрощує побудову розподільчих додатків. Основний вклад: ПВ дозволяють створювати клієнти і сервери так, що взаємодія і локальна обробка виконуються паралельно, що дає виграш в продуктивності.

Співвідношення процесів і потоків виконання. Для виконання програм операційна система створює декілька віртуальних процесорів, окремо для кожної програми. Аби відстежувати ці віртуальні процесори, операційна система підтримує таблицю процесів (process table), яка містить записи для збереження значень регістрів процесора, карт пам'яті, відкритих файлів, облікових записах користувачів, привілеях і тому подібному. Процес (process) часто визначають як виконувану програму, тобто програму, яка в даний час виконується на одному з віртуальних процесорів операційної системи. Множина процесів спільно використовують один і той же процесор та інші апаратні ресурси, це є прозорим (не заважають один одному). Для того, щоб так само відділяти процеси один від одного, операційній системі потрібна апаратна підтримка.

3.1. ПОТОКИ ВИКОНАННЯ Процеси ПРОЦЕС ОС створює віртуальні процесори для виконання програм. ОС підтримує таблицю процесів (process table) для того, щоб відслідковувати віртуальні процесори. Процес (process) програма, що виконується. Тобто це програма, яка на даний момент виконується на віртуальному процесорі ОС. ОС приділяє увагу гарантіям того, щоб незалежні процеси не порушили правильну роботу інших процесів. Тобто той факт, що велика кількість процесів спільно використовує один і той самий процесор та інші апаратні ресурси, є прозорим.

3.1. ПОТОКИ ВИКОНАННЯ Процеси і ПВ ПОТОКИ ВИКОНАННЯ Потік виконання дуже схожий на процес – може розглядатися як програма, що виконується на віртуальному процесорі. На відміну від процесу не потрібно намагатися досягти високого ступеню прозорості, оскільки це приводить до падіння продуктивності. Система потоків виконання забезпечує лише той мінімум інформації, який дозволяє спільно використовувати процесор для різних потоків виконання. В частності, контекст потоку виконання (thread context) містить просто контекст процесору і деяку іншу інформацію, необхідну для управління потоком виконання.

3.1. ПОТОКИ ВИКОНАННЯ Властивість ПВ Важливою властивістю ПВ є: зручна реалізація блокуючих системних викликів, які відбуваються без блокування всього процесу на час виконання потоку. Дана властивість значно спрощує уявлення про взаємодію як одночасне підтримання значної кількості логічних зєднань.

3.1. ПОТОКИ ВИКОНАННЯ Багатопотокові клієнти/сервери КЛІЄНТИ традиційний спосіб приховати затримки звязку – ініціювавши взаємодію перейти до іншої роботи. типовий приклад – web-браузери. СЕРВЕРИ Переваги багатопотоковості: суттєво спрощує код сервера; спрощує розробку серверів, в яких для досягнення високої продуктивності необхідне паралельне виконання декількох додатків.

3.1. ПОТОКИ ВИКОНАННЯ Багатопотоковий сервер 1. запит, що надходить з мережі; 2. потік-диспетчер; 3. запит перенап- равляється робочому потоку; 4. сервер; 5. робочий потік.

3.1. ПОТОКИ ВИКОНАННЯ Багатопотоковий сервер один з ПВ, потік-диспетчер, зчитує запити, які поступають на файлові операції; після перевірки запитів сервер вибирає (блокує) робочий ПВ, який знаходиться в стані очікування і передає запит йому; робочий ПВ здійснює блокуюче читання із локальної файлової системи, що приводить до призупинки ПВ до зчитування даних з диску; на той час, поки ПВ призупинений, управління може бути передано іншому ПВ: додаткову роботу може виконати потік-диспетчер або він може вибрати інший, готовий до запуску, робочий ПВ.

3.1. ПОТОКИ ВИКОНАННЯ Однопотоковий сервер (без ПВ) При відсутності потоків виконання – діяти так, ніби існує єдиний потік виконання. основний цикл файлового серверу отримує запит, перевіряє його і передає на виконання раніше, чим отримує слідуючий; поки сервер очікує закінчення операції – не опрацьовує запити; запити інших клієнтів не обробляються – обробляється значно меньша кількість запитів. ПВ забезпечують значне підвищення продуктивності, хоча вони запускаються на виконання почергово.

3.1. ПОТОКИ ВИКОНАННЯ Кінцевий автомат з приходом запису його перевіряє єдиний ПВ; замість блокування ПВ записує стан поточного запиту в таблицю і переходить до очікування отримання нового повідомлення; нове повідомлення: запит на здійснення нової операції – починаємо нову роботу; відповідь на попередній запит – із таблиці вибирається відповідна інформація, формується відповідь і передається клієнту.

3.1. ПОТОКИ ВИКОНАННЯ Способи побудови серверу МОДЕЛЬХАРАКТЕРИСТИКИ Багатопотоковий серверпаралельність блокуючі системні виклики Однопотоковий сервер (без ПВ) відсутність паралельності блокуючі системні виклики Кінцевий автоматпаралельність неблокуючі системні виклики

3.2. КЛІЄНТИ Інтерфейси користувачів Основна задача клієнтів – бути передавальною ланкою між користувачем і сервером. Основна функція клієнтів – підтримка інтерфейсу користувача. В багатьох випадках інтерфейс між користувачем і сервером відносно простий і вмонтований в апаратуру клієнта. Важливий клас інтерфейсів – графічні інтерфейси користувачів.

3.2. КЛІЄНТИ Cистема X-Windows (X) Х Х можна розглядати як частину ОС, яка відповідає за термінали. Х-ядро (X-kernel) Х-ядро (X-kernel) – серце системи: містить всі необхідні для управління терміналами драйвери пристроїв - сильно залежить від апаратної конфігурації; представляє собою низькорівневий інтерфейс для управління екраном і перехвату повідомлень, котрі X-lib потрапляють від клавіатури і мишки. Цей інтерфейс доступний для додатків у вигляді бібліотеки X-lib.

3.2. КЛІЄНТИ Базова організація системи X-Windows 1. додаток; 2. X-lib; 3. інтерфейс X-lib; 4. Х- протокол; 5. термінал (із дисплеєм, клавіатурою, мишкою і т.д.).

3.2. КЛІЄНТИ Програми системи X-Windows Звичайні/нормальні додатки зазвичай здійснюють (через X-lib) створення на екрані вікна, яке потім використовується для вводу-виводу чи іншої роботи. Менеджери вікон додаток, який має особливе право на роботу із всім екраном. Звичайні додатки зобовязані підчинятися обмеженням на роботу з екраном, які реалізовані в менеджері вікон.

3.2. КЛІЄНТИ Система X-Windows Х-системи Х-системи тільки надають додаткам інтерфейс користувача. Єдиною інформацією, яку додатки можуть отримувати із системи є події, які визначають основні дії користувача з підключеними до терміналу пристроями : натискання клавіш, переміщення мишки, операції з кнопками мишки.

3.2. КЛІЄНТИ Система X-Windows До програмного забезпечення клієнта входить не тільки інтерфейс користувача. На стороні клієнта виконується частина рівнів обробки даних. На основі вбудованого програмного забезпечення клієнта функціонує цілий ряд пристроїв: автовідповідачі, лічильники банкнот, зчитувачі штрих- кодів, телеприставки. В подібних випадках інтерфейс користувача є відносно невеликою частиною програмного забезпечення клієнта в порівнянні із засобами локальної обробки і комунікацій.

3.3. СЕРВЕРИ СЕРВЕР процес, який реалізує деяку службу, яка потрібна групі клієнтів. Всі сервери працюють схожим чином: очікують вхідного повідомлення, яке посилається клієнтом; перевіряють це повідомлення на правильність; очікують на слідуюче повідомлення.

3.3. СЕРВЕРИ Види і організація серверів Ітеративний сервер (iterative server) сервер сам обробляє запит і при необхідності повертає клієнту повідомлення- відповідь. Паралельний сервер (concwrent server) не обробляє повідомлення сам, а передає його в окремий ПВ чи інший процес, після чого відразу переходить в стан очікування слідуючого вхідного повідомлення. Потік чи процес, який обробляв запит, відповідає за відправлення відповіді клієнту, який прислав запит. (Багатопотоковий сервер)

3.3. СЕРВЕРИ Види серверів Сервер без фіксації звязку (stateless server) не зберігає інформацію про стан своїх клієнтів і може змінювати свій власний стан, не інформуючи про це своїх клієнтів. (Web-сервер). Cервер з фіксацією звязку (stateful server) зберігає і обробляє інформацію про своїх клієнтів. (Файловий сервер).

3.3. СЕРВЕРИ Способи переривання звязку користувач негайно закриває клієнтський додаток, що автоматично спричиняє розрив із сервером; більш правильний спосіб – пересилка між клієнтом і сервером сигналу кінця звязку (out-ofband), який повинен опрацьовуватися сервером раніше всіх інших даних, які передає клієнт. Рішення: необхідно, щоб сервер проглядав окрему кінцеву точку, на яку клієнт буде відсилати сигнал кінця звязку і одночасно (з меньшим пріоритетом) – кінцеву точку, через яку передаються дані; пересилати сигнал кінця звязку через те ж зєднання, через яке клієнт переслав свій запит.

3.3. СЕРВЕРИ Сервери обєктів СЕРВЕР ОБЄКТІВ (object server) сервер, орієнтований на підтримку розподільчих обєктів. Різниця між стандартним сервером обєктів і іншими серверами: сам по собі сервер обєктів не представляє конкретних служб. Вони реалізуться обєктами, розташованими на сервері. Сервер надає лише засоби звернення до локальних обєктів на основі запитів від віддалених клієнтів. Таким чином, можна відносно легко змінити набір служб просто додаючи чи видаляючи обєкти.

3.3. СЕРВЕРИ Сервери обєктів Сервери обєктів мають велике значення : формують будівельні блоки для організації розподільчих обєктів та виступають як місце для зберігання обєктів. Обєкт складається з 2-х частин: даних, які відображають його стан; коду, що створює реалізацію його методів. Від сервера обєктів залежить: спільне зберігання цих 2-х частин; спільне використання методів декількома обєктами.

3.3. СЕРВЕРИ Альтернативи звернень до обєктів Для будь якого обєкта, до якого відбувається звернення, сервер обєктів повинен знати який код виконувати, з якими даними працювати і т.д. Простійший підхід – вважати, що всі обєкти мають однаковий вигляд і звернення до них може здійснюватися однаково. Але даному підходу не вистачає гнучкості. Більш правильний підхід з боку сервера – підтримувати різноманітні правила обробки обєктів.

3.3. СЕРВЕРИ Адаптер обєктів Правила звернення до обєкта зазвичай називають політикою активізації (activation policies), щоб підкреслити той факт, що в багатьох випадках обєкт, перед тим як до нього можна буде звернутися,повинен бути переміщений в адресний простір серверу (тобто активізований). Механізм групування обєктів у відповідності з політикою активації – адаптер обєктів (object adapter) адаптер обєктів (object adapter). Адаптер обєктів контролює один або декілька обєктів. Оскільки сервер повинен одночасно підтримувати обєкти з різною політикою активізації, то на одному сервері може одночасно працювати декілька адаптерів обєктів.

3.3. СЕРВЕРИ Організація сервера обєктів 1. сервер; 2. обєкти; 3. заглушка обєкта (скелетон); 4. адаптер обєктів; 5. демультиплексор запитів.

3.4. ПЕРЕНЕСЕННЯ КОДУ Причини перенесення коду Традиційно перенесення коду відбувається у формі перенесення процесів (process migration), у випадку чого процес повністю переноситься з однієї машини на інші. Перенесення працюючого процесу на іншу машину – складна і не дешева процедура і для її виконання повинна бути серйозна причина. Такою причиною завжди була продуктивність Основна ідея полягає в тому, що продуктивність може рости при перенесенні процесів із сильно завантаженої на слабко завантажену машину.

3.4. ПЕРЕНЕСЕННЯ КОДУ Причини перенесення коду Алгоритм розподілу завантаження, на базі якого приймаются рішення, які включають розподілення і перерозподілення задач у відповідності з набором процесорів, відіграє важливу роль в системах інтенсивних обчислень. Але в багатьох сучасних розподілених системах оптимізація потужності обчислення – меньш важлива задача в порівнянні, із, наприклад, зниженням комунікаційного трафіку. Більш того, враховуючи гетерогенність базових платформ і компютерних мереж, підвищення продуктивності шляхом переносу коду часто базується швидше на якісних показниках чим на математичних моделях.

3.4. ПЕРЕНЕСЕННЯ КОДУ Моделі перенесення коду Хоча перенесення коду передбачає тільки переміщення коду з машини на машину, цей термін має більш широку область використання. Перенесення коду в широкому сенсі цього слова повязане з переносом програм з машини на машину з метою виконання цих програм в необхідному місці. В певних випадках, таких як перенесення процесу, також повинні бути перенесені стани програми, сигнали та інші елементи системи.

3.4. ПЕРЕНЕСЕННЯ КОДУ Види сегментів Сегмент коду частина, яка містить набір інструкцій, які здійснюються в ході виконання програми. Cегмент ресурсів складається з посилань на зовнішні ресурси, необхідні процесу (файли, принтери, інші процеси). Cегмент виконання використовується для зберігання поточного стану процесу, включаючи закриті дані, стек і лічильник програми.

3.4. ПЕРЕНЕСЕННЯ КОДУ Модель слабкої мобільності Абсолютний мінімум для перенесення коду пропонує модель слабкої мобільності (weak mobility). За цією моделлю допускається перенесення тільки сегмента коду, можливо разом з деякими даними ініціалізації. Характерною рисою слабкої мобільності є те, що перенесена програма завжди запускається із свого вихідного стану. Перевагою даного підходу є його простота. Слабка мобільність потрібна лише для того, щоб машина, на яку переноситься код, була в змозі його виконувати. Цього цілком достатньо, щоб зробити код переносним.

3.4. ПЕРЕНЕСЕННЯ КОДУ Модель сильної мобільності На противагу слабкій мобільності, в системах, які підтримують сильну мобільність (strong mobility), переноситься також і сегмент виконання. Характерна риса сильної мобільності те, що процес, який працює, може бути призупинений, перенесений на іншу машину, а його виконання повинно бути продовжене з того місця, на якому воно було зупинене. Зрозуміло, що сильна мобільність значно потужніше слабкої, але значно складнішою є і її реалізація.

3.4. ПЕРЕНЕСЕННЯ КОДУ Клонування клонування Крім перенесення процесу, що працює (міграції процесу) сильна мобільність може також здійснюватися за рахунок віддаленого клонування. На відміну від міграції процесу, клонування виконується на віддаленій машині. Клон процесу виконується паралельно оригіналу. Перевага клонування полягає у подібності із стандартними процедурами, які здійснюються в додатках. Єдина різниця між ними полягає в тому, що клонований процес виконується на іншій машині. З цієї точки зору міграція шляхом клонування – самий простий спосіб підвищення прозорості розподілення.

3.4. ПЕРЕНЕСЕННЯ КОДУ Варіанти перенесення коду Механізм перенесення Слабка мобільність Сильна мобільність Перенесення, ініційоване відправником Перенесення, ініційоване отримувачем Перенесення, ініційоване відправником Перенесення, ініційоване отримувачем Виконання в процесі- приймачі Виконання в окремому процесі Виконання в процесі- приймачі Виконання в окремому процесі Перенесення процесу Клонування процесу Перенесення процесу Клонування процесу

3.5. ПРОГРАМНІ АГЕНТИ ПРОГРАМНИЙ АГЕНТ (software agent) автономний процес, який здатний реагувати на середовище виконання і викликати зміни в середовищі виконання, можливо, в кооперації з користувачами або з іншими агентами. Властивість, яка робить агента більшим за процес – здатність функціонувати автономно і, в частності, проявляти при необхідності ініціативу.

3.5. ПРОГРАМНІ АГЕНТИ Кооперативні агенти Крім автономності важливою якістю агентів є можливість кооперуватися з іншими агентами. Обєднання автономності і кооперативності приводить до поняття КООПЕРАТИВНИЙ АГЕНТ (collaborative agent) агент, який є складовою частиною мультиагентної системи, тобто системи, в якій агенти, кооперуючись, виконують деякі загальні задачі. Здатність до кооперації з іншими абонентами є системною властивістю агентів.

3.5. ПРОГРАМНІ АГЕНТИ Мобільні агенти МОБІЛЬНИЙ АГЕНТ (mobile agent) просто агент, у якого є властивість переміщуватися з машини на машину. Мобільні агенти часто потребують підтримки сильної мобільності, хоча це і не являється абсолютно необхідним. Вимога сильної мобільності випливає з того факту, що агенти автономні і активно взаємодіють зі своїм середовищем. Перенесення агента на іншу машину без врахування його стану є достатньо складним процесом. Мобільність це загальна властивість агентів, наявність якої не приводить до виділення особливого їх класу.

3.5. ПРОГРАМНІ АГЕНТИ Інтерфейсні агенти ІНТЕРФЕЙСНИЙ АГЕНТ (interface agent) агент, який допомагає кінцевому користувачу працювати з одним чи декількома додатками. Традиційною властивістю інтерфейсного агента можна вважати здатність до навчання. Найчастіше вони взаємодіють з користувачами, забезпечуючи таким чином їм підтримку. Для розподілених систем інтерфейсним агентом може бути агент, що слідкує за взаємодіями між агентами і користувачами в деякому середовищі.

3.5. ПРОГРАМНІ АГЕНТИ Інформаційні агенти Дуже близький до інтерфейсного агенту ІНФОРМАЦІЙНИЙ АГЕНТ (information agent) Основна функція таких агентів управління інформацією із великої множини різноманітних джерел. Управління інформацією включає в себе: упорядкування, фільтрацію, порівняння і т.д. Інформаційні агенти є важливими завдяки тому факту, що вони можуть працювати з інформацією із фізично різних джерел. Стаціонарні інформаційні агенти зазвичай працюють із вхідними потоками інформації.

3.5. ПРОГРАМНІ АГЕНТИ Важливі властивості агентів ВЛАСТИВІСТЬСПІЛЬНІСТЬ ДЛЯ АГЕНТІВ ОПИС АвтономністьТакЗдатність працювати незалежно від інших. РеактивністьТакЗдатність вчасно реагувати на зміни в своєму оточенні. ПроактивністьТакЗдатність ініціювати дії, які впливають на оточення. КомунікативністьТакЗдатність обмінюватися інформацією з користувачами та іншими агентами. ТривалістьНіВідносно довга тривалість життя. МобільністьНіЗдатність переміщуватися з місця на місце. АдаптивністьНіЗдатність до навчання.

3.6. ПРОГРАМНІ АГЕНТИ Модель платформи агента 1. агент; 2. кінцева точка агента; 3. платформа агента; 4. міжплатформений звязок; 5. компоненти управління агентами; 6. канал звязку між агентами.

3.6. ПРОГРАМНІ АГЕНТИ Модель платформи агента FIPA (Foundation for Intelligent Physical Agents) Організацією FIPA (Foundation for Intelligent Physical Agents) було розроблено узагальнену модель програмних агентів. Згідно цієї моделі, агенти реєструються і працюють під управлінням платформи агентів (рис). Платформа агентів надає основні служби, необхідні мультиагентній системі. Сюди входят: механізмі створення і видалення агентів, механізми розпізнавання агентів і механізми взаємодії між агентами. Компонент управління агентами відслідковує агентів на відповідній платформі. Він представляє механізми створення і видалення агентів. Важливий компонент платформи агента : канал звязку між агентами (Agent Communication Channel, АСС). канал звязку між агентами (Agent Communication Channel, АСС). В більшості моделей мультиагентних систем агенти звязуються один з одним надсилаючи повідомлення. АСС відповідає за всі взаємодії між різними платформами агентів. В частності, АСС відповідає за надійний і направлений звязок точка-точка з іншими платформами. Канал АСС може бути реалізований просто у вигляді сервера, який відслідковує деякий порт, призначений для вхідних повідомлень, які перенаправляються іншим серверам чи агентам, що являються частиною платформи агентів.

3.6. ПРОГРАМНІ АГЕНТИ Мови взаємодії агентів Звязок між агентами відбувається за допомогою комунікаційного протоколу прикладного рівня під назвою мова взаємодії агентів (Agent Communication Language, ACL). В ACL існує жорсткий розподіл між метою повідомлення і його змістом. Повідомлення може мати тільки обмежену кількість мети. Ідея ACL полягає в тому, що агент-відправник і агент-отримувач як мінімум одинаково розуміють мету повідомлення. Більш того, мета повідомлення зазвичай визначає і реакцію отримувача. Повідомлення ACL складаються із заголовка і реального вміст. Заголовок містить поле мети повідомлення, а також поля відправника і отримувача.

3.5. ПРОГРАМНІ АГЕНТИ Мета і опис повідомлення МЕТА ПОВІДОМЛЕННЯ ОПИСЗМІТ ПОВІДОМЛЕННЯ INFORMІнформувати, що дане припущення вірне Припущення QUERY –IFЗапитати чи вірне дане припущення Припущення QUERY – REFЗапит даного обєктуВираз PROPOSEНадати пропозиціюПропозиція ACCEPT – PROPOSAL Повідомити, що дана пропозиція прийнята Ідентифікатор пропозиції REJECT – PROPOSAL Повідомити, що дана пропозиція відхилена Ідентифікатор пропозиції SUBSCRIBEПідписатися на джерело інформації Посилання на джерело

3.6. ВИСНОВКИ Процеси відіграють фундаментальну роль в розподілених системах, оскільки вони формують базис для звязку між різними машинами. Потоки виконання в розподілених системах використовуються для продовження роботи з процесором під час блокуючих операцій вводу-виводу. Є можливою побудова більш ефективних серверів, в яких декілька потоків виконання працюють одночасно. Можлива організація розподілених додатків у поняттях клієнтів і серверів. Клієнтський процес зазвичай реалізує інтерфейс користувача.

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

3.6. ВИСНОВКИ Для того, щоб підримувати перенос коду існує 2 причини: підвищення продуктивності та мобільність. Перенос коду приносить проблеми використання локальних ресурсів. Інша проблема – при переносі коду необхідно звертати увагу на гетерогенність системи. Кращий спосіб вирішення проблеми з гетерогенністю – віртуальні машини, які ефективно приховують гетерогенність за допомогою коду. Програмні агенти – спеціальний вид процесів, що працюють як автономні модулі, але здатні на кооперування з іншими агентами.

3.6. ВИСНОВКИ З точки зору розподілених систем, відмінність агентів від звичайних додатків в тому, що агенти взаємодіють один з одним за допомогою комунікаційного протоколу прикладного рівня, який називається мовою взаємодії агентів (ACL). В ACL існує чіткий розподіл між метою повідомлення та його вмістом. ACL визначає комунікаційний протокол верхнього рівня: посилка повідомлення зазвичай має на увазі конкретну реакцію отримувача на основі виключно мети повідомлення.

ДЯКУЮ ЗА УВАГУ !