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


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


Лекція 12. Моделi i системи узгодження

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

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

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

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

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


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

  • Моделi узгодження.

  • Система TIB/Rendezvous.

  • Система Jini.



1. Моделi узгодження



1.1. Типи моделей узгоджень

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

  • Моделi узгодження взаємодiяння процесiв можна роздiлити за двома вимiрами:

  • час;

  • посилання.



1.2. Типи моделей



1.2. Типи моделей (продовження)

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

  • Узгодження за поштовою скринькою передбачає незв'язнiсть за часом, але зв'язнiсть - за посиланням, а також, що повiдомлення, направленi у скриньку, можуть використовуватись сумiсно. Зв'язнiсть посилань забезпечується через визначення адреси поштової скриньки.



1.2. Типи моделей (продовження)

  • Узгодженi пiд час зiткнення процеси не мають повної iнформацiї один про одного, i не можуть безпосередньо звернутись один до одного, але збiгаються у часi. Цi системи реалiзують часто на базi подiй або систем публiкацiї/пiдписки (publish-subscribe systems). Деяк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ативним механiзмом пошуку кортежiв достатньо вказати значення полiв, за якими кортеж передається процесу.



2. Система TIB/Rendezvous



2.1. Історія розробки системи

  • Систему TIB/Rendezvous розробила компанiя ТIВСО.



2.2. Принципи побудови

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

  • повiдомлення описують самi себе, тобто свою структуру i змiст, що звiльняє процеси вiд попередньої iнформованостi про формат повiдомлень;

  • процеси не мають зв'язностi на пiдставi посилань через використання адресацiї за темою (subject-based addressing).

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



2.3. Групове розсилання адресатам за темою А



2.4. Архiтектуру глобальної мережi TIB/Rendezvous

  • Основою є групове розсилання. Кожний вузол має демон контактiв (rendezvouz demon), який вiдслiдковує вiдправлення й отримання повiдомлень. Зокрема, для публiкацiї вузол виконує групове розсилання.



2.5. Архiтектура системи TIB/Rendezvous



2.6. Таблиця пар

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



2.7. Маршрутизувальнi демони контактiв

  • Маршрутизувальнi демони контактiв (rendezvouz router daemons) дозволяють вузлам зв'язуватись з вiддаленими вузлами. Демони створюють оверлейнову мережу (overlay network) iз застосуванням протоколу TCP. Маршрутизатори прикладного рiвня утворюють вторинну мережу. Маршрутизатор знає топологiю вторинної мережi й обчислює дерево групового розсилання для публiкацiї повiдомлення в iнших мережах.



2.8. Повідомлення

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



2.9. Транспортні протоколи

  • Вiдправлення i приймання повiдомлень здiйснюються з використанням транспортних протоколiв (transport), подiбних до сокiтiв Берклi в UNIX, якi дозволяють посилати повiдомлення демонам контактiв. Транспорти виконують операцiї send (передавання повiдомлення локальному демону контактiв), sendreply (виклик для отримання вiдповiдi), sendrequest (посилання локальному демону контактiв повiдомлення для передавання базовою мережею i блокування до отримання вiдповiдi).



2.10. Механізм подій

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



2.11. Об'єкти подiй

  • Об'єкти подiй (event objects) черги под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в, то кожен з них створює за повiдомленням свiй об'єкт подiї.



2.12. Оброблення пiдписок прослуховувачем подiй



2.13. Потоки

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



2.14. Хост

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



2.15. Іменування

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



2.16. Синхронізація процесів

  • Ядро TIB/Rendezvouz мiнiмально пiдтримує синхронiзацiю процесiв i гарантує лише доставляння повiдомлень вiд одного джерела у послiдовностi FIFO. Є також служба транзакцiй, розмiщена над ядром, яка пiдтримує традицiйний обмiн повiдомленнями (transaction messaging). Надiсланi або одержанi повiдомлення можна розглядати як частину однiєї транзакцiї.



2.17. Транзакції

  • Демон транзакцiй (transaction daemon) вiдповiдає за зберiгання опублiкованих повiдомлень до моменту доставляння їх адресатам. Можлива наявнiсть кiлькох демонiв, кожен з яких вiдповiдає за частину тем певного набору. Транзакцiйний обмiн можна поєднувати з операцiями над БД й обмiном звичайними повiдомленнями.



2.18. Транзакцiйний обмiн повiдомленнями у TIB/Rendezvouz



2.19. Кешування i реплiкацiя

  • Кешування i реплiкацiя вiдбуваються з використанням додаткiв. Зокрема, для нових адресатiв можна створити фоновий процес для кешування останнiх повiдомлень.



2.20. Відмовостійкість

  • Забезпечення вiдмовостiйкiстi передбачає застосування двох способiв: надання надiйного зв'язку без утрати повiдомлень у разi збоїв для ненадiйної базової мережi i пiдтримання групи процесiв. Для надiйного зв'язку демон контактiв зберiгає повiдомлення, передане iншому демону, протягом 60 с. Вiдправлення повiдомлення супроводжується послiдовним номером, за яким демон-отримувач визначає втрату повiдомлення. Це спричиняє запит на повторне пересилання повiдомлення.



2.21. Прагматичне групове розсилання PGM

  • Використовується протокол групового розсилання транспортного рiвня - прагматичне групове розсилання PGM (Pragmatic General Multicast). Одержувач визначає втрату повiдомлення i за деревом розсилання виконує запит на повторне пересилання керованого повiдомлення з промiжних вузлiв до вiдправника включно. Для цього PGM запам'ятовує шлях i фiксує повторнi запити вiдправниками.



2.22. Сертифіковані повідомлення

  • Додатковим засобом пiдвищення надiйностi зв'язку є доставляння сертифiкованих повiдомлень (certified message delivery), за якими процес використовує окремий транспорт, який має вбудований журнал реєстрацiй (lodger) вiдправлених i отриманих повiдомлень. Журнал реалiзовано як файл, тому надiйне передавання можна забезпечити навiть у разi вiдмов процесiв.



2.23. Вiдмовостiйкiсть ранжованих процесiв

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



2.24. Безпека

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



2.25. Схема створення захищеного каналу



3. Система Jini

  • Система Jini є розподiленою системою, орiєнтованою на Java. Вона складається iз взаємопов'язаних елементiв з моделлю узгодженого регенеративного зв'язку на основi системи узгодження JavaSpace. Система JavaSpace являє собою розподiлений простiр даних, у якому зберiгаються кортежi, що є типiзованими наборами посилань на об'єкти Java.



3.1. Органiзацiя простору JavaSpace в Jini



3.2. Запис екземпляру

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



3.3. Читання екземпляру

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



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



3.5. Базові механізми

  • Нижнiй рiвень iнфраструктури мiстить базовi механiзми, зокрема пiдтримання взаємодiї за допомогою звернень RMI (вiддалений доступ до методiв) мови Java. Служба надається звичайним процесам, а також пристроям, якi програмне забезпечення Jini i Java не можуть виконувати.



3.6. Зовнішні засоби

  • На рiвнi зовнiшнiх засобiв використовуються засоби ефективної реалiзацiї служб. Верхнiй рiвень складається з клiєнтiв i служби. Програмам цього рiвня дозволяється напряму використовувати механiзми iнфраструктури Jini. Зв'язок у Jini реалiзовується за допомогою RMI, а механiзм взаємодiї має просту пiдсистему подiй i сповiщення. Подiя вiдбувається в межах об'єкта або в JavaSpace. Якщо вона цiкавила клiєнта, вiн дозволяє зареєструвати її на цьому об'єктi.



3.7. Події

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

  • Сповiщення про подiю реалiзується об'єктом, вiддаленим викликом об'єкта за схемою RMI прослуховувача (listener object). Цей об'єкт може викликатись повторно з поданням сповiщення порядкових номерiв.



3.8. Використання подiй



3.9. Набiр екземплярiв кортежiв

  • Набiр екземплярiв кортежiв для розподiлених серверiв Java Script може бути розподiлено по кiлькох машинах. Ефективна розподiлена реалiзацiя передбачає розв'язання двох проблем: емуляцiї асоцiативної без глобального пошуку; розподiлення екземплярiв кортежiв по машинах.



3.10. Розсилання кортежів

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



3.11. Іменування

  • Iменування реалiзується за допомогою служби пошуку JavaSpace прикладного рiвня, однак Jini має власну службу пошуку (lookup service) нижнього рiвня.



3.12. Ідентифікатор служби

  • Кожна служба має iдентифiкатор Service ID (Service Identifier) який являє собою унiкальне 128-бiтне значення. Iдентифiкатор служби реєструється як елемент служби (service item) у службi пошуку (можливо, кiлькох). Поле Service елемента служби надсилається на об'єкт (можливо, вiддалений через RMI), який реалiзує службу, а поле AttributeSets мiстить набiр кортежiв, що описують службу.



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

  • У системi Jini пiдтримується кiлька механiзмiв синхронiзацiї, зокрема з використанням операцiй записування read, take, а також транзакцiй.



3.14. Дiаграма органiзацiї транзакцiй в системi Jini



3.15. Робота клієнта

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



3.16. Відмовостійкість

  • Система Jini не пiдтримує вiдмовостiйкостi. Захист реалiзовується вiдповiдно до процедур RMI мови Java. За допомогою спецiальної служби авторизацiї Java JAAS (Java Authentification and Authorization Service) здiйснюються автентифiкацiя та авторизацiя користувачiв системи за допомогою вiддаленого пiдключення модуля автентифiкацiї РАМ (Pluggable Authentification Module). Вiн займає середнє положення мiж додатком i ОС.



3.17. Взаємодiя РАМ зi службами захисту



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

  • Моделi узгодження.

  • Система TIB/Rendezvous.

  • Система Jini.



Питання?

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

  • www.simulation.kiev.ua/dis/



Схожі:

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

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


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