< индекс---содержание № 6---след. статья в № 6---след. в рубрике >
УДК 004.738
ИНТЕРНЕТ-СЛУЖБА ДЛЯ ПОДДЕРЖКИ РАСПРЕДЕЛЕННЫХ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ
Р.Э. Асратян
Институт проблем управления им. В.А. Трапезникова, г. Москва
Описаны принципы организации протокола RFPP (протокола обработки удаленных пакетов файлов), специально предназначенного для поддержки взаимодействия компонентов распределенных управляющих систем. Основной акцент сделан на обеспечении разнообразных форм взаимодействия (вызов удаленных обработчиков, связь с постоянно активными агентами через очереди обслуживания, межсерверный обмен данными) и обеспечение устойчивости к сетевым сбоям. Главным объектом обработки служит “удаленный пакет наборов данных”, обладающий способностью мигрировать с сервера на сервер и аккумулировать результаты работы программных компонентов.
Развитие Интернета дало новый импульс разработкам распределенных приложений и систем управления. Системы с “большой географией”, включающие в себя сотни взаимодействующих компонентов, удаленных друг от друга на сотни и тысячи километров, уже сегодня являются реальностью [1, 2]. Тем не менее, выбор сетевых протоколов для построения таких систем и сегодня представляет собой проблему для разработчиков и администраторов. В большинстве случаев разработчики вынуждены пользоваться широкоизвестными Интернет-службами и протоколами, изначально спроектированными для решения совсем других задач: поддержки массовых коммуникаций (SMTP/POP3), электронной прессы (HTTP) и др. [2, 3].
Возникающие при этом трудности связаны, прежде всего, с тем, что семантика этих Интернет-служб не вполне адекватна потребностям распределенных информационно-управляющих систем, а акцент в их реализации сделан скорее на достижение максимальной производительности, чем на надежности и устойчивости к сетевым сбоям (что особенно четко проявляется в условиях работы с некачественными каналами связи). Наверное, многим знакома ситуация, когда вследствие разрыва сетевого соединения результаты длительной работы, например, CGI-приложения, оказываются потерянными. Этот недостаток особенно характерен для Интернет-служб, которые обычно относят к классу “online”, т. е. служб, реализующих все фазы взаимодействия (передача параметров, обработка, получение результатов и т. п.) в течение одного сеанса связи. Риск потери данных объясняется тем, что эти службы, как правило, жестко ассоциируют “контекст” сеанса связи с TCP-соединением. Поэтому разрушение соединения означает потерю “контекста” и, как следствие, результатов обработки.
Понятие “контекста” сеанса связи является основополагающим для описываемого ниже протокола RFPP (Remote File Packets Protocol – протокол обработки удаленных пакетов файлов). Главная особенность протокола заключается в том, что этот контекст ассоциируется не с сетевым соединением, а с новым, явно определяемым понятием – удаленным пакетом наборов данных (далее будем называть его просто “пакетом”). Клиент RFPP сам открывает пакет на RFPP-сервере при необходимости удаленного взаимодействия и закрывает его, когда он больше не нужен. В промежутке между этими событиями он может наполнить пакет данными, вызвать те или иные удаленные обработчики данных, получить результаты их работы, передать пакет другому клиенту и т. п. Причем все это может быть сделано или за одно TCP-соединение, или за несколько. Сохраняя идентификатор пакета, клиент всегда может восстановить контекст сеанса после случайного (или намеренного) разрыва соединения и продолжить работу.
Главная цель разработки RFPP заключалась в решении следующих задач.
 |
Создание простого, интуитивно понятного средства сетевой поддержки распределенных приложений и информационно-управляющих систем. |
|
Обеспечение защиты от потери данных в условиях некачественных каналов связи. |
|
Преодоление “водораздела” между так называемыми “online” и “offline”-взаимодействиями. Фактически, применительно к RFPP термины “online” и “offline” скорее характеризуют стиль “поведения” клиента, а не являются имманентными свойствами протокола. |
Легко заметить, что RFPP содержит отдельные элементы таких сетевых служб, как FTP (протокол передачи файлов) или RPC (удаленный вызов процедур) [3]. Автор попытался показать, что объединение этих элементов в рамках общей концепции удаленных пакетов наборов данных дает “новое качество” и новые возможности обработки. Фактически, создание распределенного приложения или системы на базе RFPP сводится к разработке набора соответствующих обработчиков, клиентов и(или) агентов, использующих уже готовые средства взаимодействия.
Безусловно, работа сервера RFPP по созданию, поддержке и уничтожению удаленных пакетов можно отнести к “накладным расходам”, связанным с реализацией протокола. Поэтому область его эффективного применения включает в себя взаимодействия, связанные с достаточно большими объемами передаваемой информации и с достаточно длительной обработкой (например, поиск информации в СУБД, удаленное формирование отчетов и т. п.). Наоборот, попытка создать на его основе что-то вроде DNS [3] вряд ли была бы оправданной.
В настоящее время RFPP-сервер реализован в двух вариантах: в форме сервиса для Windows2000 [4] и в форме “демона” для Unix FreeBSd [5]. В обоих вариантах пакеты и наборы данных организованы в файловой системе сервера. Клиентское ПО реализовано в форме библиотек функций: статической и динамической для Win32. Первые опыты применения RFPP показали его эффективность и удобство для разработчиков (в том числе для разработчиков, малознакомых с “сетевым” программированием).
1. Асратян Р.Э., Волков А.Ф., Гаджиев А.М. Автоматизированная система “Гибридная почта” // Труды ИПУ РАН. – 1999. – Т. IV. – С. 5–16.
2. Фролов А.В., Фролов Г.В. Глобальные сети компьютеров. – М.: Диалог-МИФИ, 1996. – 256 с.
3. Паркер Т. TCP/IP. Освой самостоятельно. – М.: Бином, 1997. – 448 с.
4. Widows 2000: Server и Professional / А.Г. Андреев, Е.Ю. Беззубов, М.М. Емельянов и др. – СПБ.: БХВ-Санкт-Петербург, 2001. –1055 с.
5. Келли-Бутл С. Введение в Unix. – М.: ЛОРИ, 1995. – 596 с.
( (095) 334-88-61
E-mail: rea@L9.ipu.rssi.ru
