Ієрархічна служба локалізації мобільних сутностей в розподілених системах

Локалізація мобільних сутностей на основі базової точки

Базова точка - фіксоване місце з якого відслідковуються переміщення мобільної сутності.

Як правило базова точка – місце створення або підключення мобільної сутності.

Схема мобільної ІР адресації

В ролі ідентифікатора використовується фіксована адреса мобільного хоста. Точкою доступу виступає контрольна ІР адреса.

Недолік: на основі БТ є зберігання інформації пари фіксована і біжуча адреса.

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

Основна ідея: Оптимізація пошуку за рахунок відображення локальності і мобільності сутностей в доменну структуру. Локалізація зводиться до пошуку по дереву.

Кешування вказівникі – багаторівневе кешування, яке дозволяє пришвидшити пошук мобільної сутності за рахунок використання “географічної” інформації.

Лекція 5. Організація обчислень в ОС Android

1. Загальна схема організації обчислень в ОС Android

- кожна програма стартує як окремий користувач

- схема виконання та взаємодії програм; програмні менеджери

- Dalvik -> Java

- Linux kernel -> NDK -> C

Рис.1. Загальна схема організації обчислень в ОС Android

2. Основні поняття: Context, Activity, Intent, Service

- Context -> контекст виконання програми

- Activity -> робота/завдання

- Intent -> заявка на виконання дії (повідомлення)

- Service -> фонова програма (не використовує інтерфейс користувача)

3. Структура та організація Android-програми

- структура -> набір завдань -> {Activity}

- як правило, кожне завдання прив’язується до кожного окремого стану інтерфейсу користувача (screen view)

- приклад організації Android-програми:

Рис.2. Організація простої Android-гри у вигляді п’яти завдань

- паралельне виконання процесів -> лише один процес + лише одне його завдання захоплює екран -> current foreground Activity

«There can be only one active application visible to the user at a time — specifically, a single application Activity is in the foreground at any given time.»

- Activity stack -> стек завдань

Рис.3. Схема розташування завдань у стеку

- Activities of the application (those on the stack that are paused and the one that is active) share the same VM. They also

share the same memory heap.

- стани Activity: Running, Paused, Stopped

Running: In this state, it is the top-level activity that takes up the screen and directly interacts with the user.

Paused: This happens when the activity is still visible on the screen but partially obscured by either a transparent activity or a dialog, or if the phone screen is locked. A paused activity can be killed by the Android system at any point in time (e.g., due to low memory). Note that the activity instance itself is still alive and kicking in the VM heap and waiting to be brought back to a running state.

Stopped: This happens when the activity is completely obscured by another activity and thus is no longer visible on the screen. Our AndroidBasicsStarter activity will be in this state if we start one of the test activities, for example. It also happens when a user presses the home button to go to the home screen temporarily. The system can again decide to kill the activity completely and remove it from memory if memory gets low.

- зупинка Activity -> In both the paused and stopped states, the Android system can decide to kill the activity at any point in time. It can do so politely, by first informing the activity of that by calling its finished() method, or by being bad and silently killing its process.

4. Життєвий цикл Android Activity

Activity.onCreate(): This is called when our activity is started up for the first time. Here we set up all the UI components and hook into the input system. This will only get called once in the life cycle of our activity.

Activity.onRestart(): This is called when the activity is resumed from a stopped state. It is preceded by a call to onStop().

Activity.onStart(): This is called after onCreate() or when the activity is resumed from a stopped state. In the latter case, it is preceded by a call to onRestart().

Activity.onResume(): This is called after onStart() or when the activity is resumed from a paused state (e.g., the screen is unlocked).

Activity.onPause(): This is called when the activity enters the paused state. It might be the last notification we receive, as the Android system might decide to silently kill our application. We should thus save all state we want to persist in this method!

Activity.onStop(): This is called when the activity enters the stopped state. It is preceded by a call to onPause(). This means that before an activity is stopped, it is paused first. As with onPause(), it might be the last thing we get notified of before the Android system silently kills the activity. We could also save persistent state here. However, the system might decide not to call this method and just kill the activity. As onPause() will always be called before onStop() and before the activity is silently killed, we’d rather save all our stuff in the onPause() method.

Activity.onDestroy(): This is called at the end of the activity life cycle when the activity is irrevocably destroyed. It’s the last time we can persist any information we’d like to recover the next time our activity is created anew. Note that this method

Лекція 6. Перенос коду та програмні агенти

14.1. Основні причини переносу коду

14.2. Моделі переносу коду

14.3. Взаємозв’язок переносу коду та локальних ресурсів

14.4. Програмні агенти в розподілених системах

14.5. Система D'Agent (Agent Tcl)

6.1. Основні причини переносу коду

-- перенос коду (code migration) на противагу переносу даних -> ідея оптимального співвідношення (+ автономний пошук цього співвідношення)

-- основні причини:

- підвищення обчислювальної продуктивності за рахунок перерозподілення обчислювальних процесів по хостах (з врахуванням витрат на перенос); основна ідея: збільшення загальної продуктивності розподіленої системи за рахунок міграції процесів з сильно завантажених хостів на слабо завантажені

- оптимізація мережного трафіка -> приклади: 1) взаємодія програми-клієнта з СУБД; 2) узагальнена схема клієнт-сервер; 3) розподілений пошук інформації в глобальній мережі

- забезпечення гнучкості -> розподілена прикладна програма розбивається на частини з подальшим вирішенням де яка частина програми буде виконуватись; за рахунок механізму переносу коду з’являється можливість динамічного (real-time) конфігурування: сервер надає клієнту реалізацію деякої функціональності (у вигляді виконавчого коду) лише тоді, коли це необхідно (взагалі цей код може переноситись до клієнта з сервера "третьої сторони"); наслідок: не треба мати повний ("обтяжливий" + дорогий) комплект програмного забезпечення (майбутнє)

6.2. Моделі переносу коду

С точки зору переносу коду обчислювальний процес можна поділити на три сегменти:

- сегмент коду (набір інструкцій, що складають відповідну програму)

- сегмент ресурсів (посилання на зовнішні ресурси: файли, пристрої, інші процеси і т.п.)

- сегмент виконання (структури даних, в яких зберігається біжучий стан процесу, в тому числі "приховані" дані, стек та лічильник команд)

З урахуванням цього розрізняють:

1. Модель слабкої мобільності (weak mobility) -> допускається лише перенос сегменту коду (можливо з деякими даними ініціалізації) -> перенесений процес завжди запускається з початкового стану; приклад: Java applets.

2. Модель сильної мобільності (strong mobility) -> одночасно переносяться сегмент коду та сегмент виконання -> перенесений процес запускається з тієї точки, в якій він був зупинений до моменту переносу; сильна мобільність значно переважає слабку, але як наслідок потребує більших витрат на реалізацію.

Крім цього розрізняють:

- перенос коду, ініційований відправником коду (upload / server-side computation)

- перенос коду, ініційований отримувачем коду (Java applets)

Для слабкої мобільності також розрізняють:

- перенесений код виконується в приймаючому процесі (приклад: MS Internet Explorer -> Java VM -> Java applets)

- перенесений код виконується в спеціально створеному новому процесі

Для сильної мобільності розрізняють:

- міграцію процесу (повний перенос; приклад: Agent Tcl (D'Agent))

- клонування процесу (UNIX fork -> PVM spawn; батьківській процес лишається на машині, а дочірній починає виконуватись віддалено)

6.3. Взаємозв’язок переносу коду та локальних ресурсів

-- Що робити з сегментом ресурсів під час переносу коду?

Розрізняють три типи взаємодії процесу з ресурсами (по спаданню "сили" взаємодії):

1. прив’язка по ідентифікатору (binding by identifier) -> найбільш "сильний" зв’язок; приклади: взаємодія з файлом (ім’я файлу, дескриптор файлу), взаємодія з віддаленим ресурсом (URL -> HTTP,FTP)
2. прив’язка по значенню (binding by value) -> процесу потрібне лише значення (value) ресурсу; приклад: бібліотеки функцій
3. прив’язка по типу (binding by type) -> процесу необхідний ресурс лише заданого типу; приклад: принтер, монітор

При переносі коду з’являється потреба у зміні посилань на ресурси. При цьому змінювати тип взаємодії процесу з ресурсом заборонено. З цієї точки зору розрізняють:

1. неприєднанні ресурси (unattached resources) -> ресурси можуть бути легко перенесені з одного хоста на інший; приклад: файли даних
2. приєднані ресурси (fastened resources) -> перенос або копіювання ресурсів з одного хоста на інший дуже витратні; приклад: локальні бази даних, web-сайти
3. фіксовані ресурси (fixed resources) -> ресурси прив’язані до конкретного хоста і не можуть бути перенесені на інший хост; приклад: локальні пристрої, сокети (кінцеві точки взаємодії)

Усі можливі варіанти проблеми взаємозв’язку переносу коду та локальних ресурсів і способи вирішення цих проблем можна представити у наступному вигляді.

MV - (move) перенести ресурс

GR - (global reference) організувати глобальне посилання (вказівник) на ресурс

CP - (copy) скопіювати значення ресурсу

RB - (re-binding) виконати нову прив’язку процесу до локального ресурсу

6.4. Програмні агенти в розподілених системах

-- Визначення. Програмний агент (software agent) - це програма здатна самостійно (за власною ініціативою) планувати та виконувати послідовності деяких дій задля досягнення цілей, які поставлені перед нею її розробником.

-- Основний момент: ці послідовності дій плануються ("програмуються") не розробником, а самим програмним агентом (+ ідея самопрограмування (self-programming)). Ініціативність можлива лише в тих ситуаціях, коли є вибір між двома або більше альтернативними варіантами дій. Проблема полягає в тому, що оцінити успішність (ефективність застосування) цих варіантів в деяких випадках можна лише під час їх виникнення (real-time). Саме в таких випадках доцільно використовувати технології програмних агентів та багатоагентних систем.

-- Базова класифікація: мережні агенти + обчислювальні агенти

-- Розширена класифікація:

1) за здатністю до переміщення в мережі:

- мобільні програмні агенти

- програмні агенти не здатні до переміщень

2) за призначенням:

- мережні агенти

- активні мережі (active networks)

- адаптивна маршрутизація пакетів (packet adaptive routing)

- однорангові мережі (p2p networks)

- системи управління мережею

- обчислювальні агенти

- розподіл навантаження (load balancing)

- автоматичне розпаралелення задач (automatic parallelization)

- розподілені обчислення (distributed computing)

- дослідницькі агенти (моделювання колективної поведінки)

- розважальні агенти (комп'ютерні ігри, комп'ютерна анімація)

- інтерфейсні агенти (приклад: MS Agent)

- віруси та антивіруси

-- Приклади програмних платформ для створення та використання програмних агентів: Agent Tcl (D'Agent), Java Aglets (Sun Java), Zeus (BT) та багато інших.

-- Термінологія:

mobile agent -> мобільний агент - програма здатна за власною ініціативою переміщуватись з одного хоста на інший

collaborative agent -> кооперативний агент; приклад: агент он-лайн конференції або агент системи електронної комерції; основна функція: представлення інтересів власника (користувача) в процесі взаємодії з такими самими агентами

interface (personal) agent -> інтерфейсний агент; основна функція: підтримка користувача, забезпечення універсальних інтерфейсних функцій, навчання вподобанням користувача (профілі вподобання); приклад: MS Agent

information agent -> інформаційний агент; основна функція: управління інформацією з декількох джерел

-- Стандартизація: FIPA (Foundation for Intelligent Physical Agents), www.fipa.org

6.5. Система D'Agent (Agent Tcl)

Tcl -> Tool Command Language - командна мова утиліт - скриптова мова, яка дозволяє інтегрувати різні програми, об’єкти та пристрої (розробник: корпорація Sun; найбільш відомий спосіб застосування: Tcl/Tk - створення віконних інтерфейсів в системах типу X‑Windows)

-- Визначення. D'Agent (Agent Tcl) - програмна платформа проміжного рівня, яка підтримує різні форми переносу коду, базуючись на ідеї програмного агента. Відповідно під агентом в цій системі розуміється програма здатна переміщуватись з одного хоста на інший. Агенти в системі D'Agent (Agent Tcl) пишуться на мовах, що інтерпретуються (базова мова - Tcl, взагалі агент може бути написаним на будь якій мові, що інтерпретуються). Агент виконується в процесі, що запущений інтерпретатором відповідної мови програмування.

-- Типи переносу коду, які підтримує система D'Agent (Agent Tcl):

1) ініційована відправником слабка мобільність (agent_submit)

2) сильна мобільність з переносом процесів (agent_jump)

3) сильна мобільність з клонуванням процесів (agent_fork)

-- приклад програмного агента D'Agent на мові Tcl, який переміщається з хоста на хост та виконує команду who UNIX-системи

proc all_users machines {

set list "" # створити порожній список

foreach m $machines { # для кожного з заданих хостів

agent_jump $m # переміститись на наступний хост

set users[exec who] # виконати команду who

append list $users # додати результат до списку

}

return $list # по закінченню повернути список

}

set machines … # ініціалізувати набір машин

set this_machine … # вказати хост, з якого буде стартувати агент

# створити агента та запустити його на виконання на машині this_machine

agent_submit $this_machine -procs all_users -vars machines\

-script {all_users $machines}

agent_receive … # отримати результат

-- реалізація системи D'Agent (Agent Tcl)

Система D'Agent складається з п’яти рівнів:

1 -> необхідні для роботи D'Agent складові операційної системи

2 -> управління агентами, авторизація, переміщення агентів та зв’язок між агентами

3 -> незалежна від мови програмування реалізація основних моделей агентів (основна функціональність агентів)

4 -> інтерпретатори мов програмування, що використовують функціональність з третього рівня

5 -> програмні агенти, що написані на мовах програмування з четвертого рівня