Системы мобильных агентов с настраиваемой архитектурой

• Автор: Першин, Алексей Владимирович
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2011
• Место защиты: Санкт-Петербург
• Количество страниц: 188 с. : ил.

Оглавление

Сокращения и условные обозначения

Введение.

Глава 1. Архитектуры мобильных агентов для поисковых систем

1.1. Введение

1.2. Архитектуры современных поисковых систем.

1.3. Архитектура агента для поисковых систем

1.4. Анализ задачи поиска в сети

1.4.1. Постановка задачи.

1.4.2. Модель пользователя.

1.4.3. Состояния выполнения запроса .

1.4.4. Формализация задачи распределенного поиска
1.4.5. Задача поиска авиабилета и бронирования номера в гостиннице
1.5. Выводы.
Глава 2. Архитектуры и шаблоны мобильных агентов
2.1. Введение
2.2. Адаптивный шаблон агента
2.3. Прототип модульной агентной системы
2.4. Управление перемещением
2.5. Шаблоны взаимодействия
2.6. Шаблоны организации агентов
2.7. Архитектуры бизнеслогики агента
2.7.1 . Простой рефлексивный агент
2.7.2. Рефлексивные агенты, основанные на модели
2.7.3. Целевые агенты
2.7.4. Агенты, основанные на полезности .
2.7.5. Архитектура I
2.7.6. Реактивная архитектура
2.8. Шаблоны надежности
2.9. Выводы
Глава 3. Построение моделей систем мобильных агентов
3.1. Введение
3.2. Модель сетевой среды
3.2.1. Время выполнения запроса
3.2.2. Время передачи данных в сети
3.2.3. Время реакции и теория очередей.
3.2.4. Факторы производительности сетей
3.2.5. Влияние стратегий управления потоком данных.
3.2.6. Рекомендации для эксплуатации сетей
3.2.7. Моделируемые объекты
3.2.8. Параметры моделирования.
3.2.9. Требования и ограничения модели.
3.3. Концепция системы имитационного моделирования.
3.4. Выбор системы моделирования.
3.5. Компоненты моделей .
3.5.1. Модель канала данных.. . .
3.5.2. Модель сетевого переключателя.
3.5.3. Модель генератора подтверждения
3.5.4. Модель центрального сервера
3.5.5. Модель терминала потребителя
3.5.6. Модель сервера поставщика.
3.5.7. Оценка параметров моделирования.
3.6. Выводы
Глава 4. Моделирование архитектур агентных поисковых систем
4.1. Введение
4.2. Имитационная модель поиска с независимой группой агентов
4.2.1. Модель сети
4.2.2. Алгоритмы поиска.
4.2.3. Параметры моделирования
4.2.4. Результаты моделирования.
4.3. Аналитическая модель агентной поисковой системы.
4.4. Имитационная модель поиска с агентоммаршрутизатором . .
4.4.1. Модель сети .
4.4.2. Алгоритмы поиска.
4.4.3. Параметры моделирования
4.4.4. Результаты моделирования.
4.5. Методика моделирования агентных поисковых систем
4.6. Выводы
Заключение
Приложение. Инструкция по использованию модели
Список литературы


В общем случае потребитель не обладает сведениями о том, где находится требуемый объект, поэтому искать его приходится последовательным опросом поставщиков. При этом потребитель может задать поиск первого объекта, удовлетворяющего запросу, или поиск объекта, наилучшим способом удовлетворяющего запросу. Очевидно, что разные виды запросов потребуют разных затрат времени и ресурсов. В данной главе проанализированы основные архитектуры современных поисковых систем и предложены децентрализованные варианты систем, использующих мобильных агентов. Представлена формализованная постановка задачи поиска в сети для выработки критерия оценки различных архитектур поиска. Простейшую централизованную архитектуру систем поиска в сети, осуществляющую последовательный опрос поставщиков, можно изобразить в виде схемы ira рисунке 1. Предполагается, что в этой схеме потребители посылают запросы серверу системы, выполняющему функции интерфейса (далее сервер-интерфейс). Получив запрос, сервер последовательно устанавливает связь с поставщиками, передавая запрос пользователя и получая ответ. Естественно, что при большом числе поставщиков и потребителей требуется мощный сервер, который будет загружен операциями установки связей, передачей запросов поставщикам и обработкой ответов. В общем случае время поиска для выполнения запросов п потребителей при известных т поставщиках можно представить так: Тп — (? Ил. Св — время установки связи и передачи запроса поставщику; -время локального поиска; ? Сократить время поиска можно за счет использования широковещательной или групповой рассылки запроса всем поставщикам. Однако в таком случае появится дополнительный бесполезный трафик, загружал ющий сеть, к тому же, не все сетевое оборудование поддерживает групповую адресацию. Другой способ, позволяющий сократить время поиска, заключается в построении централизованной системы, сохраняющей копии баз данных всех поставщиков. Схема централизованной архитектуры системы с общей базой данных на сервере приведена на рисунке 1. Рисунок 1. В этой схеме основной сервер содержит базу данных, дублирующую базы всех поставщиков. Он не только выполняет функции интерфейса пользователей, но и проверяет возможность удовлетворения запроса путем поиска в этой базе данных. Таким образом, в рассматриваемой архитектуре отпадает необходимость установки связей с поставщиками и ожидания результатов при выполнении поиска, однако в ней появляется новый вид сообщений - уведомления об изменениях состава базы данных. Такими сообщениями должны обмениваться главный сервер и поставщики при каждом изменении состава базы данных. Следовательно, время поиска в такой системе существенно сокращается. Его можно в первом приближении записать следующим образом: Ти = ? ИуВ, где ? B - время передачи сообщений об изменениях в базах данных поставщиков или основной базы данных на сервере. Величина второго слагаемого в приведенном выражении пропорциональна числу запросов, удовлетворенных главным сервером, плюс число запросов, удовлетворенных серверами поставщиков. Заметим, что такая архитектура реализована во многих системах бронирования авиабилетов (amadeus, sabre, galileo, worldspan). Это существенно повышает стоимость подобных систем и может рассматриваться как недостаток архитектуры. Чтобы снизить требования к оборудованию и. В этом случае все множество производителей разбивается на сегменты, в каждом из которых используется свой главный сервер, дублирующий сведения о поставщиках в своем сегменте. Любой потребитель через общедоступный сервер интерфейса системы может обратиться к любому серверу сегмента. Получив запрос, сервер сегмента действует точно так же, как главный сервер предыдущей архитектуры. Если запрос выполнить не удается, то сервер сегмента передает его в следующий сегмент. Если после обхода всех сегментов запрос остается неудовлетворенным, то он возвращается серверу интерфейса, в противном случае возвращаются результаты поиска с указанием сегмента. Схема частично централизованной архитектуры с несколькими серверами изображена на рисунке 1. Рисунок 1.