Лекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України


НазваЛекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Дата конвертації07.03.2013
Розмір445 b.
ТипЛекція


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

  • Діденко Дмитро Георгійович

  • Старший викладач кафедри ММСА ННК «ІПСА»

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

  • «Київський політехнічний інститут»

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


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

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

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

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

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

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



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

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



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

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



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

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



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

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



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



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

  • Перемикання 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.6. Потоки виконання

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



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

  • Застосовувати б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.8. Схема виконання полегшених процесiв рiвня ядра i потокiв рiвня користувача



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

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



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

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



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

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



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

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



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

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



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

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



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

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



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

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



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



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

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



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

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



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

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



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

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



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

  • Одне з основних завдань кл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.1. Органiзацiя системи X Windows



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

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



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

  • 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.4. Інтеграція у складеному документі

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



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

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



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

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



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

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



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

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



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

  • Стандартним сервером або просто сервером є процес реал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.1. Типи клієнтів

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



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



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

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



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



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

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



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

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



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

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



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

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



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

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



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

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



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

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



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



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

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



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

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



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

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



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



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

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



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

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



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

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



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

  • Модел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.8. Способи перенесення коду



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

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



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

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



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

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



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

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



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

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

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



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

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

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



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



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

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



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

  • У раз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. Види взаємодії (продовження)

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



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

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



4.18. Приклад

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



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

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



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



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

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



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

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



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

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



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

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



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

  • Найважлив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ї команди тощо).



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

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

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



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

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



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



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

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



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

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



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

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



5.6. Цiлi та змiст повiдомлень



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

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



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



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

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



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

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

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

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

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

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



Питання?

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

  • www.simulation.kiev.ua/dis/



Схожі:

Лекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 18. Методи захисту розподiлених iнформацiйних систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Захист розподiлених iнформацiйних систем у сучасних умовах порушення безпеки у комп'ютерних системах призводить до значних фiнансових...
Лекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Використовується переважно у ос windows, хоча була реалізована на декількох платформах
Лекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 06. Промисловий стандарт corba діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Першi версiї специфiкацiї з'явились на початку 90-х рокiв. Поширеними є версiї 4 i 3
Лекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 03. Програмне забезпечення проміжного рівня Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Концепції програмних рішень Основними програмними компонентами рiс є ос I системи промiжного рiвня
Лекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 01. Структура І основні задачі створення розподілених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Визначення розподіленої системи Розподілена система це комплекс незалежних комп'ютерів, які користувач сприймає як єдину об'єднану...
Лекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 04. Зв'язок процесів на рівні протоколів Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Т. к. Ріс побудовані з використанням принципа відкритості, то використовуються стандартні протоколи обміну даними між процесами
Лекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 12. Моделi I системи узгодження Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Типи моделей узгоджень Системи узгодження передбачають вiддiлення обчислювальних процесiв вiд механiзмiв їх узгодження
Лекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Прототипом системи є система afs на 10000 робочих станцiй I має ту ж саму afs virtue органiзацiю
Лекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 11. Розподiленi системи документiв Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
За стандартизацiю протоколiв удосконалення мiжоперацiйної взаємодiї та удосконалення систем на основi World Wide Web (www) з 1994...
Лекція 13. Процеси розподiлених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 05. Зв'язок на основі повідомлень І потоків Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Зв'язок на основi повiдомлень Зв'язок на пiдставi повiдомлень дозволяє уникнути блокування клiєнта у процесi здiйснення операцiї,...

Додайте кнопку на своєму сайті:
dok.znaimo.com.ua


База даних захищена авторським правом ©dok.znaimo.com.ua 2013
звернутися до адміністрації
dok.znaimo.com.ua
Головна сторінка