Лекція 13. Процеси розподiлених систем

Діденко Д.Г. © 2010

Лекція 13. Процеси розподiлених систем

Діденко Дмитро ГеоргійовичСтарший викладач кафедри ММСА ННК «ІПСА»

Національний технічний університет України «Київський політехнічний інститут»

м. Київ, Україна

www.simulation.kiev.ua/dis/ Процеси розподiлених систем


2

1. Потоки виконання.

2. Процеси клiєнтiв.

3. Процеси серверiв.

4. Перенесення коду.

5. Програмнi агенти.

Питання заняття



3

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

1. Потоки виконання (threads)



4

Перемикання процесора мiж двома процесами - досить складна операцiя, оскiльки потребує збереження контексту процесора (регiстрiв, вказiвникiв тощо). Пiдтримання багатьох процесiв часто потребує пiдкачування (swapping) процесiв в операцiйному запам'ятовувальному пристрої (ОЗП) з диска. Потоки також реалiзуються бiльш простими програмами порiвняно з процесами.

1.1. Перемикання процесора



5

За контекстом потокiв можна виокремити особливостi реалiзацiї потокiв для розподiлених i нерозподiлених систем. Багатопотоковi реалiзацiї в них мають рiзнi особливостi. У нерозподiлених системах багатопотоковi процеси не блокуються за наявностi блокувальних системних викликiв потокiв. Багатопотокову структуру часто застосовують для побудови великих додаткiв, що характерно, наприклад, для середовища UNIX.

1.2. Багатопотоковi процеси



6

Мiжпроцесорна взаємодiя через механiзм мiжпроцесорних комунiкацiй IPC (Inter Process Communication) передбачає наявнiсть каналiв (iменованих), черги повiдомлень i сегментiв пам'ятi сумiсного використання.

1.3. Мiжпроцесорна взаємодiя



7

1.4. Схема перемикання контекстiв пiд час виконання IPC

S1 - перемикання з простору користувача в простiр ядра;

S2 - перемикання контексту з процесу А на процес В;

S3 - перемикання з простору ядра ОС у простiр користувача.



8

Перемикання S1 потребує змiни карти пам'ятi у блоцi керування пам'яттю MMU (Memory Management Unit), а також скидання асоцiативного буфера сторiнок TLB (Translation Lookaside Buffer). У ядрi вiдбувається перемикання S2, за яким може бути активiзовано перемикання S3, що знову змiнює карти пам'ятi MMU i TLB.

1.5. Перемикання контекстів



9

Потоки виконання зазвичай мають вигляд пакетiв з вiдповiдними можливостями створення i знищення потокiв та роботи зi змiнними синхронiзацiї (м'ютекси, умовнi змiннi). Пакети реалiзуються з використанням бiблiотек для роботи з потоками в режимi користувача або iз застосуванням ядра, яке керує потоками.

1.6. Потоки виконання



10

Застосовувати бiблiотеки простiше й дешевше. Процедури бiблiотек виконуються в адресному просторi користувача iз застосуванням стекiв. Перемикання потокiв стосуються лише регiстрiв процесора i немає потреби змiнювати карту пам'ятi, контролювати завантаження процесора тощо. Недолiками є блокування процесу за блокувального системного виклику. Цей недолiк можна подолати реалiзацiєю потокiв виконання у ядрi ОС. Це потребує системних викликiв для виконання операцiй з потоками (створення, знищення, синхронiзацiя тощо), що зводить нанiвець переваги.

1.7. Застосування бібліотек



11

1.8. Схема виконання полегшених процесiв рiвня ядра i потокiв рiвня

користувача



12

На один процес може бути кiлька полегшених процесiв. Система надає пакет потокiв для асинхронного виконання на користувацькому рiвнi додатками операцiй зi створення i знищення потокiв виконання.

1.9. Відношення процесів і полегшених процесів



13

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

1.10. Синхронізація



14

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

1.11. Прицес виконання



15

Недолiком використання полегшених процесiв є потреба їх створення. Альтернативою є пiдхiд активiзацiї планувальника (scheduler activations), за яким функцiї планувальника передаються в пакет потокiв пiд час блокування ядра.

1.12. Недоліки полегшених процесів



16

Важливою властивiстю потокiв у розподiлених системах є зручна реалiзацiя блокувальних системних викликiв без блокування всього процесу на час виконання потоку. Це дозволяє подати взаємодiї як одночасне пiдтримання значної кiлькостi логiчних з'єднань. Як приклад можна навести багатопотоковi процеси клiєнта i серверiв.

1.13. Особливості блокування



17

Зокрема, клiєнт як багатопотоковий Web-браузер спочатку отримує основний HTML-файл, а далi активiзує потоки виконання, якi вiдповiдають за довантаження iнших частин сторiнки. Кожний потiк виконує окремi з'єднання iз сервером i отримує данi, зокрема iз застосуванням блокувальних системних викликiв.

1.14. Приклад багатопотоковий Web-браузер



18

Додатковою перевагою багатопотоковостi є можливiсть використовувати реплiкованi сервери, що забезпечує паралельнiсть передавання даних. Реплiкованi сервери розмiщенi в одному й тому ж мiсцi i мають однакове iм'я. Iз надходженням запиту на Web-сторiнку запит передається одному iз серверiв, наприклад, iз застосуванням алгоритму циклiчного обслуговування або iншого алгоритму вирiвнювання навантаження.

1.15. Репліковані сервери



19

Багатопотоковiсть серверiв дозволяє спростити код сервера i розроблення серверiв для органiзацiї паралельного виконання кiлькох додаткiв. Наприклад, файловий сервер перiодично блокується очiкуванням диску пiд час оброблення отриманого запиту i повернення вiдповiдi.

1.16. Багатопотоковість сервера



20

1.17. Багатопотоковий сервер за схемою «диспетчер-робочий

потiк»



21

Нехай файловий сервер перiодично блокується очiкуванням диску. «Потiк-диспетчер» зчитує вхiднi запити на файловi операцiї, вибирає робочий потiк, який перебуває у станi очiкування, блокує його i передає йому запит. Цей потiк виконує блокувальне зчитування з локальної файлової системи, що призводить до його призупинення до моменту зчитування з диску. На час призупинення потоку диспетчер може передати керування iншому робочому потоку виконання.

1.20. Багатопотоковий сервер за схемою «диспетчер-робочий потiк»



22

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

1.21. Відсутність потоків



23

Можливе також застосування сервера як великого скiнченного автомата. Запит, що надiйшов, перевiряє єдиний потiк виконання. Вiн може звернутись до кешу або до диска. Однак замiсть блокування потiк виконання записує стан потокового запиту в таблицю i переходить до очiкування та отримання нового повiдомлення. Це повiдомлення може бути як вiдповiддю, так i результатом вiдповiдi на запит.

1.22. Сервер як скінчений автомат



24

Таким чином, потоки дозволяють зберегти iдею послiдовностi процесiв (зокрема, пiд час RPC роботи з диском) i паралельнiсть роботи, що пiдвищує продуктивнiсть роботи системи.

1.23. Особливості роботи потоків



25

Одне з основних завдань клiєнта - забезпечити iнтерфейс мiж користувачем i вiддаленим сервером. Поширеним є застосування графiчних iнтерфейсiв, серед яких важливе мiсце займає система X Windows. Система включає Х-ядро (X-kernel), яке мiстить потрiбнi для керування термiналом драйвери, i має базову органiзацiю. Iнтерфейс нижнього рiвня, який надає Х-ядро, є доступним додаткам завдяки бiблiотецi X-lib. Система має два типи програм: звичайнi додатки i менеджери вiкон.

2. Процеси клiєнтiв



26

2.1. Органiзацiя системи X Windows



27

Додатки викликають через Xlib створення на екранi вiкна для введення i виведення. Система забезпечує для активних вiкон пересилання всiх повiдомлень вiд «мишки» i клавiатури додатком. Додаток менеджера вiкон обмежує використання вiкон звичайними додатками (наприклад, обмеження на перекривання вiкон, колiр).

2.2. Робота з вікнами



28

X-ядро i додатки можуть бути розташованi на рiзних машинах. За допомогою X-протоколу i комунiкацiйного протоколу мережi екземпляри Xlib можуть обмiнюватись даними i подiями, що забезпечує створення рiзноманiтних варiантiв архiтектури «клiєнт-сервер». У найпростiших випадках ядро мiститься в однiй машинi, а код додатка - в iншiй, яку називають X-термiналом (x-terminal).

2.3. Розташування X-ядра



29

Iнтерфейс користувача дозволяє iнтегрувати рiзнi документи у складений документ (compound document) з приховуванням додаткiв якi керують цими документами.

2.4. Інтеграція у складеному документі



30

Клiєнтське програмне забезпечення охоплює також засоби локального оброблення i комунiкацiї, зокрема додатки «клiєнт-сервер» (Наприклад, лiчильники купюр, зчитувачi кодiв, автовiдповiдачi тощо).

2.5. Засоби локального оброблення i комунiкацiї



31

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

2.6. Прозорiсть розподiлення



32

Усi реплiки отримують одне й те саме звернення. Замiсник клiєнта забезпечує прозоре збирання всiх вiдповiдей i пересилає клiєнту одне з повернених значень.

2.7. Реплікація



33

Прозорiсть до збоїв у програмному забезпеченнi промiжного рiвня пiдтримується конфiгуруванням, яке передбачає багатократнi спроби зв'язку iз сервером i вибiр у разi потреби iншого сервера.

2.8. Прозорiсть до збоїв



34

Стандартним сервером або просто сервером є процес реалiзацiї деякої служби, потрiбної групi клiєнтiв. За органiзацiєю розрiзняють iтеративнi сервери (iterative server), якi самi обробляють запит i, у разi потреби, повертають клiєнту вiдповiдь, та паралельнi сервери (concurrent server), якi передають повiдомлення у потiк виконання або в iнший процес, обробляють запит i надсилають вiдповiдь (наприклад, в UNIX).

3. Процеси серверiв



35

За способом звернення клiєнта до сервера розрiзняють процеси iз запитом у кiнцеву точку (endpoint) або порт машини iз сервером, i процеси iз запитом з динамiчним визначенням кiнцевої точки, наприклад, з використанням демона.

3.1. Типи клієнтів



36

3.2. Прив'язування клiєнта до сервера iз застосуванням демона

DCE



37

Демон DCE (Distributed Computer Environment) переглядає загальнодоступнi кiнцевi точки. Для пiдвищення продуктивностi застосовують суперсервер (superserver), який переглядає всi кiнцевi точки запитаної служби i розгалужує процес оброблення серед серверiв.

3.3. Демон DCE (Distributed Computer Environment)



38

3.4. Прив'язування клiєнта до сервера з використанням

суперсервера UNIX



39

За перериванням роботи сервера розрiзняють кiлька способiв розривання зв'язку мiж клiєнтом i сервером. Найпростiший - це застосування клiєнтського додатка, що призводить до переривання зв'язку. Ще один спосiб - надсилання один одному сигналу кiнця зв'язку (out-of-band), який обробляється з вищим прiоритетом.

3.5. Види розірвання зв'язку



40

За зберiганням сервером iнформацiї про клiєнта розрiзняють сервери без фiксацiї стану (stateless server) - Web-сервери - i сервери з фiксацiєю стану (stateful server) - файловi сервери. В останньому випадку ведеться таблиця пар (клiєнт, файл), яка дозволяє вiдслiдковувати пересилання останнiх версiй файлу в разi збоїв.

3.6. Типи серверів



41

Сервером об'єктiв (object server) називають сервер, орiєнтований на пiдтримання розподiлених об'єктiв. На вiдмiну вiд стандартного сервера сервер об'єктiв не є конкретною службою, а лише надає засоби доступу до локальних об'єктiв за запитами вiд вiддалених клiєнтiв. Сервер об'єктiв - це мiсце для зберiгання об'єктiв.

3.7. Сервер об'єктiв (object server)



42

Об'єкт складається з двох частин: даних, якi вiдображають його стани, i кода, який реалiзує його методи. За умови однакового подання звернення до них однакове, що характерно для середовищ DCE. Для рiзних об'єктiв є й рiзнi способи звернення до них. Зокрема, за пiдтримання сервером кiнцевих потокiв виконання, по одному на кожний об'єкт, сервер передає об'єкту запит. Можна виокремити також потiк виконання за кожним запитом, однак при цьому треба захистити об'єкт вiд одночасного доступу.

3.7. Сервер об'єктiв (продовження)



43

Правила доступу до об'єкта називають полiтикою активiзацiї (activation policies), оскiльки об'єкт перемiщується в адресний простiр сервера.

3.9. Полiтика активiзацiї



44

Механiзм групування об'єктiв вiдповiдно до полiтики активiзацiї кожного з них називають адаптером об'єктiв (object adapter) або пакувальником об'єктiв (object wrapper). Адаптер контролює один або кiлька об'єктiв. На серверi можуть одночасно працювати кiлька адаптерiв об'єктiв. Пiсля отримання сервером запиту на звернення до об'єкта цей запит спочатку передається вiдповiдному адаптеру об'єктiв.

3.10. Адаптер об'єктiв (object adapter)



45

Адаптер об'єктiв вибирає iз запиту посилання на об'єкт i надсилає запит через серверну заглушку об'єкта вiдповiдно до своєї полiтики активiзацiї. Заглушка зазвичай генерується з визначення iнтерфейсу об'єкта, виконує демаршалiнг запиту i звертається до вiдповiдного методу.

3.11. Робота адаптера об'єктiв



46

3.12. Сервер об'єктiв з рiзною полiтикою активiзацiї



47

Перенесення коду часто зумовлено потребою збiльшити продуктивнiсть розподiленої системи. Наприклад, у системi «клiєнт-сервер» iснують ситуацiї, в яких частину клiєнтських операцiй передано на сервер для зменшення трафiку «клiєнт-сервер» за рахунок передавання лише результатiв оброблення iнформацiї телекомунiкацiйними каналами.

4. Перенесення коду



48

У системах з iнтерактивною взаємодiєю сервера i клiєнта виникає потреба перенесення операцiй iз сервера на клiєнта. Метою перенесення може бути забезпечення паралельного оброблення даних кiлькома клiєнтами, що дозволяє уникнути проблем, пов'язаних з паралельним програмуванням, i спростити програмне забезпечення. Наприклад, у випадку пошуку у Web має сенс реалiзувати пошуковий запит у виглядi невеликої мобiльної програми, яка переноситься iз сайту на сайт. Поширення копiй таких програм серед сайтiв дозволяє лiнiйно збiльщувати швидкiсть пошуку.

4.1. Мета перенесення коду



49

Перенесення кодiв збiльшує також гнучкiсть системи за рахунок динамiчного реконфiгурування розподiленої системи. Наприклад, клiєнт може спочатку активiзувати потрiбне програмне забезпечення i лише потiм звертатись до сервера.

4.2. Переваги перенесення коду



50

4.3. Динамiчне конфiгурування клiєнта для зв'язку iз сервером



51

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

4.4. Стандартизацiя протоколу завантаження коду



52

Фактично перенесення коду передбачає перенесення параметрiв середовища реалiзацiї цього коду i зберiгання можливостей взаємодiї з iншими процесами на iнших машинах. Така iнтерпретацiя потребує моделi перенесення коду.

4.5. Модель перенесення коду



53

Процес можна подiлити на сегмент коду, який мiстить набiр виконуваних iнструкцiй, сегмент ресурсiв з посиланням на зовнiшнi ресурс (файли, принтери тощо), сегмент виконання для зберiгання поточного стану процесу (зокрема, стека i лiчильника програми).

4.6. Склад моделі



54

Моделi перенесення коду можна подiлити на моделi зi слабкою мобiльнiстю (weak mobility) i сильною мобiльнiстю (strong mobility). У слабкої мобiльностi переноситься лише сегмент коду i, можливо, деякi данi iнiцiалiзацiї, а перенесена програма завжди запускається зi свого вихiдного стану (наприклад, Java-аплети). Перевагою таких моделей є простота.

4.7. Види моделей перенесення коду



55

4.8. Способи перенесення коду



56

У разi сильної мобiльностi додатково переноситься сегмент виконання. При цьому процес може бути призупинений i продовжено виконання пiсля перенесення на iншу машину. Прикладом є система D'Agents.

4.9. Сильна мобільність



57

Якщо перенесення iнiцiюється вiдправником, код знаходиться постiйно або виконується цiєю ж машиною i сам процес перенесення простiший (наприклад, у разi завантаження програми на сервер або передавання пошукових програм через Iнтернет на сервер БД для виконання запиту).

4.10. Відправник-ініціатор



58

Якщо перенесення iнiцiюється одержувачем (наприклад, Java-аплети), машина iнiцiює виконання перенесення. Приклад виконання коду в процесi-приймачi - Java-аплети, завантаженi у Web-браузер. Недолiком є слабка захищенiсть вiд випадкового або зловмисного виконання.

4.11. Одержувач-ініціатор



59

Пiд час клонування створюється i виконується процес на вiддаленiй машинi, наприклад в UNIX зi створенням дочiрнiх процесiв.

4.12. Клонування процесів



60

• сильний зв'язок, коли процес використовує саме той ресурс, на який посилається, наприклад, прив'язування за iдентифiкатором (binding by identifier) з використанням URL-адреси або посилання на FTP-сервер;

• зв'язок, за яким процес потребує лише значення ресурсу, наприклад, у разi прив'язування за значенням (binding by value) до стандартних бiблiотек С або Java;

4.13. Типи зв'язку процесу з ресурсами



61

• слабкий зв'язок використання ресурсу певного типу, зокрема прив'язування за типом (binding by type) з посиланням на принтери, монiтори тощо;

• зв'язок ресурсу з машиною можна подiлити на неприєднанi ресурси (unattached resource), зв'язанi ресурси (fastened resource) i фiксованi ресурси (fixed resource), якi неможливо перенести з машини.

4.13. Типи зв'язку процесу з ресурсами (продовження)



62

4.14. Варiанти перенесення коду на iншу машину

Прив'язування ресурсу до процесу

Прив'язування ресурсу до машини

Неприєднаний ресурс

Зв'язаний ресурс

Фiксований ресурс

За iдентифiкатором MV (або GR) GR (або MV) GR

За значенням CP (або MV, GR) GR (або СР) GR

За типом RB (або MV, CP) RB (або GR, CP) RB (або GR)

Позначення:GR - органiзувати глобальне посилання; MV - перенести ресурс; CP - копiювати значення ресурсу; RB - виконати нове прив'язування процесу до локального ресурсу.



63

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

4.15. Обмеження для гетерогенних систем



64

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

4.16. Види взаємодії



65

Якщо вдається позбавитись даних, залежних вiд платформи, то перенесення стає можливим. Так, у мовах С, Java перенесення можливе лише в момент виклику пiдпрограми. Тому виконувальна система створює машинонезалежну копiю - стек перенесення (migration stack), який оновлюється пiд час виклику пiдпрограми або повернення керування з пiдпрограми.

4.16. Види взаємодії (продовження)



66

Поширеним для гетерогенних систем є пiдхiд, за яким перенесення коду вирiшується засобами мов сценарiїв, зокрема Java, з використанням вiртуальних машин.

4.17. Перенесення з використанням віртуальних машин



67

Прикладом системи з перенесенням коду є система d'Agent (або Agent TCL), побудована на концепцiї програмного агента, який перемiщується з машини на машину. Програма пишеться на iнтерпретаторi, а мобiльнiсть пiдтримується слабкою мобiльнiстю, сильною мобiльнiстю з перенесенням процесiв i з клонуванням процесiв.

4.18. Приклад



68

Система складається з п'яти рiвнiв, з яких нижнiй подiбний до сокiтiв Берклi i надає механiзми для роботи з повiдомленнями TCP та E-mail.

4.19. Склад системи d'Agent



69

4.20. Архiтектура системи

5 Агенти

4 Інтерпретатор Tcl/Tk

Інтерпретатор Scheme

Інтерпретатор Java

3 Узагальнений агент RTS

2 Сервер

1 TCP/IP E-mail



70

Нижнiй рiвень забезпечує механiзм роботи з повiдомленнями TCP/IP та E-mail.

4.20.1. Робота нижнього рівня



71

Сервер вiдповiдає за керування агентами, авторизацiю i керування зв'язком агентiв з наданням кожному агенту локального унiфiкованого iдентифiкатора ID. Мережева адреса визначається парою <мережа, ID>.

4.20.2. Другий рівень



72

Третiй рiвень мiстить ядро для пiдтримання основних моделей агентiв (запуск i завершення їх роботи, засоби використання операцiй, перенесення коду i зв'язку агентiв).

4.20.3. Третiй рiвень



73

Iдентифiкатори четвертого рiвня мiстять компоненти iнтерпретацiї, модулi безпеки, iнтерфейс з рiвнем ядра i окремий модуль для перехоплення стану агента для пiдтримання сильної мобiльностi. Кожний агент п'ятого рiвня виконується в окремому процесi.

4.20.4. Четвертий рiвень



74

Найважливiшою частиною є подання стану агента. Так, у Tcl застосовують таблицi глобальних змiнних iнтерпретатора i системних програм разом зi стеком командних викликiв i визначення процесiв сценарiїв. Для виконання базової команди Tcl, яка викликається не з процедури користувача, будується запис, який вмiщується в стек команд (command stack) i визначає стан агента. Запис мiстить всi данi, потрiбнi для виконання (значення параметрiв, значення вказiвникiв на процедури реалiзацiї команди тощо).

4.21. Стан агента



75

Програмним агентом (software agent) називають автономний процес, спроможний реагувати на середовище виконання i зумовлювати змiни у середовищi виконання, можливо разом з iншими програмними агентами.

Виокремлюють кооперативнi (collaborative agent), мобiльнi (mobile agent), iнтерфейснi (interface agent) та iнформацiйнi (information agent) агенти.

5. Програмнi агенти



76

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

5.1. Види агентів



77

5.2. Узагальнена платформа агента згiдно з FIP (Foundation for Intelligent Physical Agents)



78

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

5.3. Компоненти керування агентами



79

Канал зв'язку мiж агентами АСС (Agent Communication Channel) вiдповiдає за взаємодiю мiж рiзними платформами агентiв, зокрема у виглядi сервера (d'Agent). Зв'язок мiж АСС здiйснюється за допомогою протоколу IIOP (Internet Inter-ORB Protocol).

5.4. Канал зв'язку мiж агентами



80

Зв'язок мiж агентами вiдбувається за допомогою комунiкацiйного протоколу прикладного рiвня, який називають мовою взаємодiї агентiв ACL (Agent Communication Language). В ACL для повiдомлення видiляють обмежену кiлькiсть цiлей i змiст. Агент-вiдправник i агент отримувач однаково розумiють мету повiдомлення, яка однозначно визначає реагування отримувача.

5.5. Зв'язок мiж агентами



81

5.6. Цiлi та змiст повiдомленьМета Опис Змiст повiдомлення

INFORM Iнформувати, що повiдомлення iстинне

Припущення

QUERY-REF Запит об'єкта Вираз

ACCEPT_PROPOSAL Повiдомлення про прийняття пропозицiї

Iдентифiкатор пропозицiї

PROPOSE Надати пропозицiю Пропозицiя

REJECT - PROPOSAL Повiдомити, що цю пропозицiю вiдхилено

Iдентифiкатор

REQUEST Запитати виконання дiї Специфiкацiя дiї

SUBSCRIBE Пiдписатись на джерело iнформацiї Посилання на джерело

QUERY – IF Запитати, чи справжня ця пропозицiя Пропозицiя

CFP Запитати пропозицiю Залежнiсть вiд пропозицiї



82

Повiдомлення ACL мiстить заголовок, поля вiдправника та одержувача, повiдомлення, iнформацiю, потрiбну для правильної iнтерпретацiї змiсту, i змiст повiдомлення. Додатковi поля називають онтологiєю (ontology).

5.7. Склад повідомлення



83

5.8. Приклад повiдомлення ACL

Поле Значення

Мета INFORM

Вiдправник max@http ://facts_of_deck-j ane .ua:4572

Одержувач kovan@iiop://many_lom.ua:6731

Мова Prolog

Онтологiя Geneology

Змiст female(jane).parent(jane.sam.eva)



84

Поля - мова, онтологiя - вiдносяться до змiсту повiдомлення. Мова визначає, що повiдомлення - це набiр виразiв мовою Prolog, онтологiя визначає гiнеалогiчну iнформацiю.

5.8. Приклад повiдомлення ACL (продовження)



85

1. Потоки виконання.

2. Процеси клiєнтiв.

3. Процеси серверiв.

4. Перенесення коду.

5. Програмнi агенти.

Питання заняття


Питання?

Розподілені інформаційні системи

www.simulation.kiev.ua/dis/

Documents

Лекція 13. Процеси розподiлених систем