Лекція 13. Процеси розподiлених систем
Post on 01-Jan-2016
74 Views
Preview:
DESCRIPTION
TRANSCRIPT
Діденко Д.Г. © 2010
Лекція 13. Процеси розподiлених систем
Діденко Дмитро ГеоргійовичСтарший викладач кафедри ММСА ННК «ІПСА»
Національний технічний університет України «Київський політехнічний інститут»
м. Київ, Україна
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
2
1. Потоки виконання.
2. Процеси клiєнтiв.
3. Процеси серверiв.
4. Перенесення коду.
5. Програмнi агенти.
Питання заняття
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
3
Потоки виконання (threads) являють собою бiльш тонке розподiлення пiд час оброблення даних, нiж процеси оброблення даних. Процес часто визначається програмою, яка виконується одним iз вiртуальних процесорiв ОС. Вiдслiдковуються процеси за допомогою таблиць процесiв (process table), якi мiстять записи даних (значення регiстрiв, процесора, карти пам'ятi тощо). Пiд час формування процесу ОС має створити абсолютно незалежний адресний простiр.
1. Потоки виконання (threads)
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
4
Перемикання процесора мiж двома процесами - досить складна операцiя, оскiльки потребує збереження контексту процесора (регiстрiв, вказiвникiв тощо). Пiдтримання багатьох процесiв часто потребує пiдкачування (swapping) процесiв в операцiйному запам'ятовувальному пристрої (ОЗП) з диска. Потоки також реалiзуються бiльш простими програмами порiвняно з процесами.
1.1. Перемикання процесора
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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 процеси
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
6
Мiжпроцесорна взаємодiя через механiзм мiжпроцесорних комунiкацiй IPC (Inter Process Communication) передбачає наявнiсть каналiв (iменованих), черги повiдомлень i сегментiв пам'ятi сумiсного використання.
1.3. Мiжпроцесорна взаємодiя
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
7
1.4. Схема перемикання контекстiв пiд час виконання IPC
S1 - перемикання з простору користувача в простiр ядра;
S2 - перемикання контексту з процесу А на процес В;
S3 - перемикання з простору ядра ОС у простiр користувача.
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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. Перемикання контекстів
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
9
Потоки виконання зазвичай мають вигляд пакетiв з вiдповiдними можливостями створення i знищення потокiв та роботи зi змiнними синхронiзацiї (м'ютекси, умовнi змiннi). Пакети реалiзуються з використанням бiблiотек для роботи з потоками в режимi користувача або iз застосуванням ядра, яке керує потоками.
1.6. Потоки виконання
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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. Застосування бібліотек
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
11
1.8. Схема виконання полегшених процесiв рiвня ядра i потокiв рiвня
користувача
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
12
На один процес може бути кiлька полегшених процесiв. Система надає пакет потокiв для асинхронного виконання на користувацькому рiвнi додатками операцiй зi створення i знищення потокiв виконання.
1.9. Відношення процесів і полегшених процесів
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
13
Полегшений процес отримує власний стек i вказiвник на пошук потоку. Таблиця потокiв виконання використовується полегшеними процесами сумiсно, а її захист вiд одночасного доступу реалiзується за допомогою м'ютексiв, створених у просторi користувача, тобто синхронiзацiя не потребує втручання ядра.
1.10. Синхронізація
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
14
Процес виконання блокувального системного виклику переходить до режиму ядра, а ОС може прийняти рiшення про перехiд на iнший полегшений процес, не повiдомляючи додатку. Найбiльш полегшенi процеси можуть бути пристосованi для роботи в мультипроцесорному середовищi, що забезпечує паралельнiсть їх виконання.
1.11. Прицес виконання
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
15
Недолiком використання полегшених процесiв є потреба їх створення. Альтернативою є пiдхiд активiзацiї планувальника (scheduler activations), за яким функцiї планувальника передаються в пакет потокiв пiд час блокування ядра.
1.12. Недоліки полегшених процесів
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
16
Важливою властивiстю потокiв у розподiлених системах є зручна реалiзацiя блокувальних системних викликiв без блокування всього процесу на час виконання потоку. Це дозволяє подати взаємодiї як одночасне пiдтримання значної кiлькостi логiчних з'єднань. Як приклад можна навести багатопотоковi процеси клiєнта i серверiв.
1.13. Особливості блокування
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
17
Зокрема, клiєнт як багатопотоковий Web-браузер спочатку отримує основний HTML-файл, а далi активiзує потоки виконання, якi вiдповiдають за довантаження iнших частин сторiнки. Кожний потiк виконує окремi з'єднання iз сервером i отримує данi, зокрема iз застосуванням блокувальних системних викликiв.
1.14. Приклад багатопотоковий Web-браузер
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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. Репліковані сервери
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
19
Багатопотоковiсть серверiв дозволяє спростити код сервера i розроблення серверiв для органiзацiї паралельного виконання кiлькох додаткiв. Наприклад, файловий сервер перiодично блокується очiкуванням диску пiд час оброблення отриманого запиту i повернення вiдповiдi.
1.16. Багатопотоковість сервера
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
20
1.17. Багатопотоковий сервер за схемою «диспетчер-робочий
потiк»
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
21
Нехай файловий сервер перiодично блокується очiкуванням диску. «Потiк-диспетчер» зчитує вхiднi запити на файловi операцiї, вибирає робочий потiк, який перебуває у станi очiкування, блокує його i передає йому запит. Цей потiк виконує блокувальне зчитування з локальної файлової системи, що призводить до його призупинення до моменту зчитування з диску. На час призупинення потоку диспетчер може передати керування iншому робочому потоку виконання.
1.20. Багатопотоковий сервер за схемою «диспетчер-робочий потiк»
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
22
Якщо немає потокiв виконання, файловий сервер змушений був би чекати завершення дискових операцiй до оброблення наступного запиту, тобто багатопотокове виконання збiльшує продуктивнiсть оброблення за рахунок бiльш повного завантаження процесора машини.
1.21. Відсутність потоків
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
23
Можливе також застосування сервера як великого скiнченного автомата. Запит, що надiйшов, перевiряє єдиний потiк виконання. Вiн може звернутись до кешу або до диска. Однак замiсть блокування потiк виконання записує стан потокового запиту в таблицю i переходить до очiкування та отримання нового повiдомлення. Це повiдомлення може бути як вiдповiддю, так i результатом вiдповiдi на запит.
1.22. Сервер як скінчений автомат
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
24
Таким чином, потоки дозволяють зберегти iдею послiдовностi процесiв (зокрема, пiд час RPC роботи з диском) i паралельнiсть роботи, що пiдвищує продуктивнiсть роботи системи.
1.23. Особливості роботи потоків
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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в
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
26
2.1. Органiзацiя системи X Windows
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
27
Додатки викликають через Xlib створення на екранi вiкна для введення i виведення. Система забезпечує для активних вiкон пересилання всiх повiдомлень вiд «мишки» i клавiатури додатком. Додаток менеджера вiкон обмежує використання вiкон звичайними додатками (наприклад, обмеження на перекривання вiкон, колiр).
2.2. Робота з вікнами
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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-ядра
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
29
Iнтерфейс користувача дозволяє iнтегрувати рiзнi документи у складений документ (compound document) з приховуванням додаткiв якi керують цими документами.
2.4. Інтеграція у складеному документі
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
30
Клiєнтське програмне забезпечення охоплює також засоби локального оброблення i комунiкацiї, зокрема додатки «клiєнт-сервер» (Наприклад, лiчильники купюр, зчитувачi кодiв, автовiдповiдачi тощо).
2.5. Засоби локального оброблення i комунiкацiї
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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лення
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
32
Усi реплiки отримують одне й те саме звернення. Замiсник клiєнта забезпечує прозоре збирання всiх вiдповiдей i пересилає клiєнту одне з повернених значень.
2.7. Реплікація
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
33
Прозорiсть до збоїв у програмному забезпеченнi промiжного рiвня пiдтримується конфiгуруванням, яке передбачає багатократнi спроби зв'язку iз сервером i вибiр у разi потреби iншого сервера.
2.8. Прозорiсть до збоїв
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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в
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
35
За способом звернення клiєнта до сервера розрiзняють процеси iз запитом у кiнцеву точку (endpoint) або порт машини iз сервером, i процеси iз запитом з динамiчним визначенням кiнцевої точки, наприклад, з використанням демона.
3.1. Типи клієнтів
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
36
3.2. Прив'язування клiєнта до сервера iз застосуванням демона
DCE
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
37
Демон DCE (Distributed Computer Environment) переглядає загальнодоступнi кiнцевi точки. Для пiдвищення продуктивностi застосовують суперсервер (superserver), який переглядає всi кiнцевi точки запитаної служби i розгалужує процес оброблення серед серверiв.
3.3. Демон DCE (Distributed Computer Environment)
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
38
3.4. Прив'язування клiєнта до сервера з використанням
суперсервера UNIX
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
39
За перериванням роботи сервера розрiзняють кiлька способiв розривання зв'язку мiж клiєнтом i сервером. Найпростiший - це застосування клiєнтського додатка, що призводить до переривання зв'язку. Ще один спосiб - надсилання один одному сигналу кiнця зв'язку (out-of-band), який обробляється з вищим прiоритетом.
3.5. Види розірвання зв'язку
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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. Типи серверів
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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)
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
42
Об'єкт складається з двох частин: даних, якi вiдображають його стани, i кода, який реалiзує його методи. За умови однакового подання звернення до них однакове, що характерно для середовищ DCE. Для рiзних об'єктiв є й рiзнi способи звернення до них. Зокрема, за пiдтримання сервером кiнцевих потокiв виконання, по одному на кожний об'єкт, сервер передає об'єкту запит. Можна виокремити також потiк виконання за кожним запитом, однак при цьому треба захистити об'єкт вiд одночасного доступу.
3.7. Сервер об'єктiв (продовження)
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
43
Правила доступу до об'єкта називають полiтикою активiзацiї (activation policies), оскiльки об'єкт перемiщується в адресний простiр сервера.
3.9. Полiтика активiзацiї
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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)
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
45
Адаптер об'єктiв вибирає iз запиту посилання на об'єкт i надсилає запит через серверну заглушку об'єкта вiдповiдно до своєї полiтики активiзацiї. Заглушка зазвичай генерується з визначення iнтерфейсу об'єкта, виконує демаршалiнг запиту i звертається до вiдповiдного методу.
3.11. Робота адаптера об'єктiв
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
46
3.12. Сервер об'єктiв з рiзною полiтикою активiзацiї
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
47
Перенесення коду часто зумовлено потребою збiльшити продуктивнiсть розподiленої системи. Наприклад, у системi «клiєнт-сервер» iснують ситуацiї, в яких частину клiєнтських операцiй передано на сервер для зменшення трафiку «клiєнт-сервер» за рахунок передавання лише результатiв оброблення iнформацiї телекомунiкацiйними каналами.
4. Перенесення коду
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
48
У системах з iнтерактивною взаємодiєю сервера i клiєнта виникає потреба перенесення операцiй iз сервера на клiєнта. Метою перенесення може бути забезпечення паралельного оброблення даних кiлькома клiєнтами, що дозволяє уникнути проблем, пов'язаних з паралельним програмуванням, i спростити програмне забезпечення. Наприклад, у випадку пошуку у Web має сенс реалiзувати пошуковий запит у виглядi невеликої мобiльної програми, яка переноситься iз сайту на сайт. Поширення копiй таких програм серед сайтiв дозволяє лiнiйно збiльщувати швидкiсть пошуку.
4.1. Мета перенесення коду
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
49
Перенесення кодiв збiльшує також гнучкiсть системи за рахунок динамiчного реконфiгурування розподiленої системи. Наприклад, клiєнт може спочатку активiзувати потрiбне програмне забезпечення i лише потiм звертатись до сервера.
4.2. Переваги перенесення коду
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
50
4.3. Динамiчне конфiгурування клiєнта для зв'язку iз сервером
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
51
Така схема потребує стандартизацiї протоколу завантаження коду зi сховища коду i його активiзацiї. Код вилучається у клiєнта, якщо потреби в ньому бiльше немає. Недолiком є зменшення безпеки роботи системи.
4.4. Стандартизацiя протоколу завантаження коду
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
52
Фактично перенесення коду передбачає перенесення параметрiв середовища реалiзацiї цього коду i зберiгання можливостей взаємодiї з iншими процесами на iнших машинах. Така iнтерпретацiя потребує моделi перенесення коду.
4.5. Модель перенесення коду
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
53
Процес можна подiлити на сегмент коду, який мiстить набiр виконуваних iнструкцiй, сегмент ресурсiв з посиланням на зовнiшнi ресурс (файли, принтери тощо), сегмент виконання для зберiгання поточного стану процесу (зокрема, стека i лiчильника програми).
4.6. Склад моделі
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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. Види моделей перенесення коду
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
55
4.8. Способи перенесення коду
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
56
У разi сильної мобiльностi додатково переноситься сегмент виконання. При цьому процес може бути призупинений i продовжено виконання пiсля перенесення на iншу машину. Прикладом є система D'Agents.
4.9. Сильна мобільність
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
57
Якщо перенесення iнiцiюється вiдправником, код знаходиться постiйно або виконується цiєю ж машиною i сам процес перенесення простiший (наприклад, у разi завантаження програми на сервер або передавання пошукових програм через Iнтернет на сервер БД для виконання запиту).
4.10. Відправник-ініціатор
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
58
Якщо перенесення iнiцiюється одержувачем (наприклад, Java-аплети), машина iнiцiює виконання перенесення. Приклад виконання коду в процесi-приймачi - Java-аплети, завантаженi у Web-браузер. Недолiком є слабка захищенiсть вiд випадкового або зловмисного виконання.
4.11. Одержувач-ініціатор
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
59
Пiд час клонування створюється i виконується процес на вiддаленiй машинi, наприклад в UNIX зi створенням дочiрнiх процесiв.
4.12. Клонування процесів
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
60
• сильний зв'язок, коли процес використовує саме той ресурс, на який посилається, наприклад, прив'язування за iдентифiкатором (binding by identifier) з використанням URL-адреси або посилання на FTP-сервер;
• зв'язок, за яким процес потребує лише значення ресурсу, наприклад, у разi прив'язування за значенням (binding by value) до стандартних бiблiотек С або Java;
4.13. Типи зв'язку процесу з ресурсами
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
61
• слабкий зв'язок використання ресурсу певного типу, зокрема прив'язування за типом (binding by type) з посиланням на принтери, монiтори тощо;
• зв'язок ресурсу з машиною можна подiлити на неприєднанi ресурси (unattached resource), зв'язанi ресурси (fastened resource) i фiксованi ресурси (fixed resource), якi неможливо перенести з машини.
4.13. Типи зв'язку процесу з ресурсами (продовження)
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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 - виконати нове прив'язування процесу до локального ресурсу.
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
63
Наявнiсть рiзних платформ у гетерогенних системах накладає додатковi обмеження щодо перенесення коду, зокрема зумовлене перекомпiляцiєю.
4.15. Обмеження для гетерогенних систем
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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. Види взаємодії
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
65
Якщо вдається позбавитись даних, залежних вiд платформи, то перенесення стає можливим. Так, у мовах С, Java перенесення можливе лише в момент виклику пiдпрограми. Тому виконувальна система створює машинонезалежну копiю - стек перенесення (migration stack), який оновлюється пiд час виклику пiдпрограми або повернення керування з пiдпрограми.
4.16. Види взаємодії (продовження)
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
66
Поширеним для гетерогенних систем є пiдхiд, за яким перенесення коду вирiшується засобами мов сценарiїв, зокрема Java, з використанням вiртуальних машин.
4.17. Перенесення з використанням віртуальних машин
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
67
Прикладом системи з перенесенням коду є система d'Agent (або Agent TCL), побудована на концепцiї програмного агента, який перемiщується з машини на машину. Програма пишеться на iнтерпретаторi, а мобiльнiсть пiдтримується слабкою мобiльнiстю, сильною мобiльнiстю з перенесенням процесiв i з клонуванням процесiв.
4.18. Приклад
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
68
Система складається з п'яти рiвнiв, з яких нижнiй подiбний до сокiтiв Берклi i надає механiзми для роботи з повiдомленнями TCP та E-mail.
4.19. Склад системи d'Agent
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
69
4.20. Архiтектура системи
5 Агенти
4 Інтерпретатор Tcl/Tk
Інтерпретатор Scheme
Інтерпретатор Java
3 Узагальнений агент RTS
2 Сервер
1 TCP/IP E-mail
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
70
Нижнiй рiвень забезпечує механiзм роботи з повiдомленнями TCP/IP та E-mail.
4.20.1. Робота нижнього рівня
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
71
Сервер вiдповiдає за керування агентами, авторизацiю i керування зв'язком агентiв з наданням кожному агенту локального унiфiкованого iдентифiкатора ID. Мережева адреса визначається парою <мережа, ID>.
4.20.2. Другий рівень
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
72
Третiй рiвень мiстить ядро для пiдтримання основних моделей агентiв (запуск i завершення їх роботи, засоби використання операцiй, перенесення коду i зв'язку агентiв).
4.20.3. Третiй рiвень
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
73
Iдентифiкатори четвертого рiвня мiстять компоненти iнтерпретацiї, модулi безпеки, iнтерфейс з рiвнем ядра i окремий модуль для перехоплення стану агента для пiдтримання сильної мобiльностi. Кожний агент п'ятого рiвня виконується в окремому процесi.
4.20.4. Четвертий рiвень
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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. Стан агента
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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 агенти
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
76
Кооперативним агентом називають агента мультиагентної системи, який вирiшує деякi загальнi завдання. Мобiльним агентом називають агента, який може перемiщуватися з машини на машину. Iнтерфейсний агент дозволяє користувачу працювати з кiлькома додатками. Iнформацiйний агент може керувати iнформацiєю, яка надходить iз множини iнформацiйних джерел.
5.1. Види агентів
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
77
5.2. Узагальнена платформа агента згiдно з FIP (Foundation for Intelligent Physical Agents)
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
78
Компоненти керування агентами надають службi iменувань такi механiзми: створення i знищення агентiв, перегляду кiнцевої точки на наявнiсть агента. Служба каталогiв грунтується на використаннi атрибутiв i дозволяє виявити наявнiсть бiльших агентiв на платформi.
5.3. Компоненти керування агентами
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
79
Канал зв'язку мiж агентами АСС (Agent Communication Channel) вiдповiдає за взаємодiю мiж рiзними платформами агентiв, зокрема у виглядi сервера (d'Agent). Зв'язок мiж АСС здiйснюється за допомогою протоколу IIOP (Internet Inter-ORB Protocol).
5.4. Канал зв'язку мiж агентами
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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ж агентами
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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ї
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
82
Повiдомлення ACL мiстить заголовок, поля вiдправника та одержувача, повiдомлення, iнформацiю, потрiбну для правильної iнтерпретацiї змiсту, i змiст повiдомлення. Додатковi поля називають онтологiєю (ontology).
5.7. Склад повідомлення
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
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)
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
84
Поля - мова, онтологiя - вiдносяться до змiсту повiдомлення. Мова визначає, що повiдомлення - це набiр виразiв мовою Prolog, онтологiя визначає гiнеалогiчну iнформацiю.
5.8. Приклад повiдомлення ACL (продовження)
www.simulation.kiev.ua/dis/ Процеси розподiлених систем
Діденко Д.Г. © 2010
85
1. Потоки виконання.
2. Процеси клiєнтiв.
3. Процеси серверiв.
4. Перенесення коду.
5. Програмнi агенти.
Питання заняття
Діденко Д.Г. © 2010
Питання?
Розподілені інформаційні системи
www.simulation.kiev.ua/dis/
top related