Распределенные системы обработки информации (стр. 6 из 7)
Более слабая связь - процессу нужно только значение;
Наиболее слабая форма связи – процесс указывает лишь на использование ресурса определенного типа.
Программный агент.
Автономный процесс, способный реагировать на среду исполнения и вызывать в ней изменения, возможно в кооперации с другими агентами (кооперативные агенты) и пользователем. Агент может функционировать автономно, в том числе проявлять инициативу. В мультиагентной системе фигурируют кооперативные агенты, решающие общую задачу.
2.11 Модель клиент-сервер
Серверы – процессы, реализующие службы и предоставляющие к ним доступ.
Клиенты – процессы, использующие эти службы.
Рассмотрим на примере доступа к БД:
При трехуровневой организации системы имеем следующие логические уровни:
· Пользовательский интерфейс (ПИ на рисунке).
· Обработки (О).
· Данных (непосредственная работа с БД).
Варианты физического разделения уровней между узлами:
На этом рисунке клиент «утолщается» слева направо.
Взаимодействие клиента с сервером происходит следующим образом:
2.12 Общие сведение об именовании объектов и службе именования
Именование – способ определения местонахождения распределенных объектов, при котором осуществляется управление пространствами имен, представляющими собой наборы связей между именами объектов и ссылками на них.
Контекст именования – последовательность простых имен, идентифицирующая объект. Например “UEFA”, “England”, “Premier”, “Chelsea”.
Операции:
Связывание – регистрация объекта-сервиса по имени и объектной ссылке. Используется при добавлении нового объекта в систему или при перемещении / копировании существующего объекта.
Разрешение – получение ссылки на объект по его имени. Используется клиентом для получения доступа к методам объекта.
Размещение мобильных сущностей.
Мобильные сущности – это те объекты, которые могут гулять по разным хостам. В этом случае пространство имен удобно разбить на 3 уровня:
· Глобальный
· Административный
· Управленческий
В 1 и 2 помещаются объекты, которые перемещаются относительно редко. Здесь эффективно кэширование путей.
В 3 объекты гуляют часто, и для них используется следующая система:
По имени объекта служба именования определяет его идентификатор, затем служба локализации по ид находит его физический адрес.
2.12 Общие сведения о синхронизации в РСОИ
У каждого узла свой системный таймер. Возникает проблема синхронизации часов. Пусть у узла р время Ср(t), тогда:
где ρ – максимальная скорость дрейфа времени, t - UTC. Если требуется рассинхронизация не более δ, то через каждые
необходима синхронизация часов.
Алгоритм Кристиана.
Есть узел, принимающий сигналы точного времени – сервер времени. Остальные узлы через каждые
обращаются к серверу и получают значение времени. Здесь есть 2 момента:
Необходимо время на запрос и возврат результата. Решение: если время запрошено в момент Т0, а получено в момент Т1, то установить часы на полученное время + (Т1-Т0)/2.
Если часы отстают, то мы их доставляем. А если часы спешат, то мы их должны ставить назад. А это не допустимо. Тогда мы не одномоментно подстраиваем часы, а растягиваем это во времени, просто замедляя их ход.
Алгоритм Беркли.
Один узел – демон – периодически собирает времена остальных узлов, получает среднее и рассылает обратно.
Логические часы. Алгоритм Лампорта.
Есть ситуации, когда важно не точное время выполнения процесса, а точная последовательность выполнения. Для таких случаев используют достаточно часто алгоритм Лампорта синхронизации логических часов.
Лампорт определил отношение: «Происходит раньше». Оно обозначается: a - b. Это значит, что все процессы согласны с тем, что событие а происходит раньше b.
· Для одного процесса, если а раньше b, то отношение выполняется.
· Если а - посылка сообщения, а b – получение того же сообщения, то отношение тоже выполняется.
· Отношение транзитивно.
В алгоритме каждому событию a ставится метка времени C(a). Эта метка должна быть принята как достоверно правильная всеми процессами. То есть если действительно a - b, то C(a) < C(b). Каждому сообщению прикрепляется временная метка. Получатель сравнивает ее со своим временем. Если его время меньше метки, то оно устанавливается равным метка+1. Даже если 2 сообщения посланы почти одновременно, их метки различаются.
2.13 Жизненный цикл распределенных объектов
2.13.1 Cоздание объектов
Требуется создать объект в адресном пространстве (АП) сервера (конструктор создал бы в АП клиента). Для этого необходима фабрика. Чтобы найти фабрику, необходим искатель фабрик. Чтобы найти искатель фабрик, используется сервер именования или трейдинг.
2.13.2 Миграция объектов.
Объектная миграция – копирование или перемещение объекта сервера с 1 машины на другую. Чтобы объект позволял миграцию, необходим интерфейс, реализующий операции copy и move с параметром – искателем фабрик. Через фабрику создается объект на новом месте, в него копируется состояние исходного объекта. Далее в случае перемещения исходный объект удаляется. При копировании создается новая ссылка на объект (т.к. исходный объект остается).
При перемещении: Есть объект в каком-то адресном пространстве. При перемещении он оставляет заместителя, а в новом АП формируется скелетон. Такая схема прозрачна для клиента: он не знает, что происходили перемещения. При получении запроса ответ может пойти по прямой, если известно, кто запросил сервис этого удаленного объекта.
