WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 |
Московский государственный технический университет имени Н.Э.Баумана Кафедра САПР Трудоношин В.А., Федорук В.Г.

Технология организации взаимодействия параллельно выполняющихся программ в сетях ЭВМ Данное пособие содержит описание технологии организации взаимодействия прикладных программ, параллельно функционирующих на различных узлах вычислительной сети в среде ОС UNIX. Формулируются требования к такой технологии, описывается предлагаемая модель взаимодействия. Приведен пример использования технологии.

1. Введение Одной из наиболее актуальных проблем в разработке современных систем автоматизированного проектирования (САПР) и иных сложных программных систем является организация кооперативного решения прикладных задач параллельно функционирующими на различных узлах локальной вычислительной сети (ЛВС) подсистемами.

Решение проблемы невозможно без создания технологии и средств, обеспечивающих взаимодействие параллельно выполняющихся прикладных программ (ПП).

Такая технология должна отвечать набору, по крайней мере, следующих требований.

1. Обеспечивать связь между всеми ПП, принимающими участие в кооперативном решении прикладной задачи.

2. Позволять динамически (в ходе совместной работы) изменяться множеству взаимодействующих ПП. Т.е. любая ПП в любой момент должна иметь возможность включиться в совместную работу и без разрушительных последствий выйти из нее.

3. Поддерживать широковещательное распространение информации между ПП как в режиме оповещения, так и в режиме запроса, требующего ответа.

4. Обеспечивать как синхронный, так и асинхронный режимы обработки в ПП пересылаемой между ними информации.

5. Не фиксировать каким-либо образом смысл или содержание пересылаемых сообщений.

6. Позволять ПП динамически регистрировать свой интерес к сообщениям определенного типа и/или содержания и обеспечивать фильтрацию распределяемых сообщений.

7. Обеспечивать корректное конвертирование данных различных типов при их пересылке между ПП, выполняющимися на ЭВМ различной архитектуры.

8. Давать широкие возможности создания синхронных и асинхронных прикладных протоколов взаимодействия ПП.

9. Функционировать в среде ОС UNIX, как в основной операционной среде САПР.

Ниже дается краткий обзор существующих технологий и средств организации взаимодействия ПП в ОС UNIX, предлагается модель взаимодействия, отвечающая перечисленным требованиям, кратко описывается ее реализация в среде ОС UNIX и приводится пример использования.

2. Существующие средства взаимодействия Современные версии ОС UNIX стандартно предоставляют прикладным программистам следующие средства разработки распределенных приложений:

1. реализованный в виде библиотеки функций языка программирования СИ т.н.

socket-интерфейс к транспортному уровню стека протоколов сетевого взаимодействия;

2. интерфейс транспортного уровня (TLI) к средствам коммуникации;

3. средства удаленного вызова процедур (RPC - Remote Procedure Call).

Наибольшее распространение при построении ЛВС из UNIX-машин получил комплекс протоколов TCP/IP.

Socket-интерфейс был первоначально разработан для версий BSD4.2 и BSD4.3 ОС UNIX.

Socket представляет собой канал двунаправленной связи с коммуникационной средой ЛВС, для манипулирования которым используется обычный файловый дескриптор ОС UNIX. Библиотека socket-интерфейса включает в себя функции открытия и закрытия socket'а, привязки к socket'у сетевого идентификатора, "прослушивания" сети и приема запросов на соединение через socket (на стороне сервера), инициализации соединения через socket (на стороне клиента), обмена данными и др.

Интерфейс транспортного уровня (TLI - Transport Level Interface) идет на смену socketинтерфейсу, используя ту же идеологию, но обеспечивая более высокую степень независимости прикладных программ от используемых сетевых протоколов.

Оба интерфейса поддерживают модель взаимодействия "клиент-сервер" и различные типы связи (с установлением соединения - потоковый тип, без установления - дэйтаграммный), различные режимы (синхронный и асинхронный) и дают возможность использовать стандартные операции ввода-вывода ОС UNIX.

Однако, недостатком средств, предоставляемых двумя этими интерфейсами, с точки зрения прикладного программиста является их "низкоуровневость", возлагающая на него необходимость разработки средств:

• упаковки/распаковки данных сложной структуры в последовательные ("плоские") сообщения;

• кодирования/декодирования передаваемых данных с учетом возможного различного представления данных одного типа на ЭВМ различного типа и т.п.

Наиболее удобны для прикладного программиста высокоуровневые RPC-средства, первоначально разработанные фирмой Sun Microsystems и ставшие международным промышленным стандартом. Основные достоинства этих средств составляют:

1. способ вызова удаленных ПП, функционирующих на различных узлах ЛВС, синтаксически подобен вызову локальных функций программы на языке программирования СИ;

2. автоматическое использование для внешнего представления данных промышленного стандарта XDR (eXternal Data Representation);

3. независимость прикладной программы от используемых для коммуникации в сети транспортных протоколов;

4. наличие средств, позволяющих при необходимости управлять выбором и параметрами используемого транспорта;

5. возможность передачи стандартными средствами сложно организованных структур данных (списков, деревьев и т.п.).

Проведенный анализ средств взаимодействия показал, что именно RPC-средства, хотя они и реализуют классическую модель "клиент-сервер", в наибольшей степени удобны для создания технологии, отвечающей требованиям, перечисленным выше.



В основе этой технологии лежит описываемая далее модель взаимодействия.

3. Модель взаимодействия Используемая в технологии модель взаимодействия построена на основе модели, предложенной организацией CAD Framework Initiative в ее стандарте DIS-92-5-3 1.Inter-Tool Communication Programming Interface.

Любая ПП, нуждающаяся в обмене информацией с другими ПП, выполняющимися одновременно с ней, должна подключиться к коммуникационной среде.

Коммуникационная среда покрывает одну локальную ЭВМ или несколько узлов вычислительной сети. Границы среды динамически меняются с подключением/отключением от нее ПП. Работой коммуникационной среды управляет коммуникационный сервер, резидентный на одном из узлов сети.

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

ПП, подключенные к коммуникационной среде, получают возможность посылать и принимать через открытые каналы связи сообщения.

Сообщения характеризуются именем (играющим роль, по сути дела, типа сообщения) и имеют тело. Имена (типы) сообщений и содержащаяся в них информация никак рассматриваемой моделью не регламентируются.

Тело сообщения состоит из конечного числа слотов. Слот характеризуется именем, типом содержащегося в нем значения и самим значением. Допустимыми типами слотов являются:

1. длинное целое число;

2. число с плавающей точкой удвоенной точности;

3. строка символов, представляющая собой массив символов, ограниченный нулевым байтом;

4. массив произвольных байт указанной длины.

Доступ к слоту тела сообщения может осуществляться как по его имени, так и по номеру в теле. При пересылке сообщения с ЭВМ одного типа на ЭВМ другого типа гарантируется корректное преобразование значений слотов первых трех типов в машинный формат ЭВМ-приемника из формата ЭВМ-источника. Массив же байт пересылается без какихлибо преобразований.

Допустимы сообщения следующих трех видов:

1. оповещение - сообщение, не предполагающее ответа;

2. запрос - сообщение, предполагающее ответ на него;

3. ответ - сообщение, посылаемое в ответ на запрос.

Сообщение, направляемое ПП в коммуникационную среду через канал связи, является широковещательным по определению, т.е. направляется всем без исключения ПП, подключенным в данный момент к коммуникационной среде (в том числе и самой посылающей ПП). Нет способа послать сообщение целенаправленно какой-либо ПП.

Для того, чтобы получать сообщения определенного типа и содержания, ПП должна зарегистрировать свой интерес, создав для соответствующего канала связи объект, называемый приемником.

При создании приемника ПП обязана специфицировать:

1. вид интересующих сообщений и режим обработки запросов;

2. имя сообщения;

3. контекст в виде тела-образца для сравнения;

4. функцию-обработчик, асинхронно вызываемую при поступлении сообщения через данный приемник.

Допустимы два режима обработки запросов - пассивный и активный. Активный режим подразумевает намерение ответить на полученный запрос, пассивный - оставить запрос без ответа. Зарегистрировать свой интерес в получении запроса одного и того же типа может любое количество ПП, но ответ должен быть только один.

Каждое сообщение любого вида, поступившее в коммуникационную среду от любого ПП, "фильтруется" через все имеющиеся приемники.

Считается, что сообщение интересует ПП, если:

1. вид поступившего сообщения соответствует виду, определяемому приемником;

2. имя сообщения и имя, определяемое приемником, совпадают;

3. тело сообщения отвечает контексту приемника в смысле:

а) тело сообщения содержит в себе слоты одноименные и однотипные всем слотам контекста (при этом в сопоставлении участвуют только слоты типов "строка символов" и "длинное целое число");

б) значения всех слотов совпадают.

В случае удачного сопоставления автоматически и асинхронно вызывается функцияобработчик, ассоциированная с данным приемником. Функции в качестве одного из аргументов передается для обработки полученное сообщение.

В течение времени выполнения функции-обработчика никакие обращения к ПП через коммуникационную среду невозможны. Кроме необходимости учета данного обстоятельства никакие другие особые требования к функциям-обработчикам не предъявляются.

В ситуациях, когда вычисление ответа требует заметного времени и/или связано с обращениями, в свою очередь, с запросами через коммуникационную среду к третьим ПП, функция имеет возможность отложить запрос на неопределенное время. ПП может позже в любой удобный момент инициировать "посылку" ей отложенного запроса.

Сформированный функцией-обработчиком ответ рассылается через коммуникационную среду всем заинтересованным получателям (в том числе, конечно, и ПП-источнику запроса).

Если для получения запроса определенного типа в среде имеется несколько приемников для разных ПП, то запрос последовательно будет пересылаться к ПП через каждый из них, пока не будет получен первый ответ. Нет средств управления порядком перебора приемников.





Если для данного запроса в среде нет ни одного приемника или ни одна ПП не смогла дать ответ на запрос, то ПП, пославшая запрос, получит соответствующее уведомление.

С точки зрения организации взаимодействия с ПП-партнерами все ПП могут быть условно разделены на две группы.

1. Программы-"серверы", предназначенные только для обслуживания запросов ПП"клиентов" (хотя для этого им может потребоваться, в свою очередь, обращение с запросами к другим ПП-"серверам"). Никакой самостоятельной активности такие программы не проявляют.

2. ПП, самостоятельно решающие прикладные задачи. Такие ПП могут информировать ПП-партнеров о ходе своего решения, делать запросы касательно интересующих данных, отвечать на запросы заинтересованных партнеров.

Типичная последовательность действий ПП первой группы при работе с коммуникационной средой выглядит следующим образом.

1. Подключение к коммуникационной среде.

2. Создание одного или нескольких каналов связи с коммуникационной средой.

3. Создание приемников, выражающих интерес ПП к получению необходимых запросов.

4. Переход в состояние ожидания поступления запросов (путем выполнения, например бесконечного цикла, тело которого составляет системный вызов pause).

5. Обработка в функциях-обработчиках входящих сообщений, прошедших фильтрацию через приемники.

ПП второй группы много сложнее. Для них типичная последовательность действий в части взаимодействия через коммуникационную среду выглядит следующим образом.

1. Подключение к коммуникационной среде.

2. Создание одного или нескольких каналов связи с коммуникационной средой.

3. Создание приемников, выражающих интерес ПП к получению необходимых сообщений.

4. Выполнение действий, связанных с решением прикладной задачи, и посылка в необходимые моменты исходящих сообщений вида "оповещение" или "запрос".

5. Асинхронная обработка в функциях-обработчиках входящих сообщений, прошедших фильтрацию через приемники.

6. Закрытие (разрушение) всех каналов связи с коммуникационной средой и отключение от нее.

Рассмотренная модель взаимодействия не накладывает никаких ограничений ни на логику функционирования ПП, ни на тип рассылаемых сообщений. В задачу прикладных программистов входит разработка прикладных протоколов, требуемых для кооперативного решения прикладных задач, и создание необходимых словарей сообщений.

4. Реализация модели Для реализации рассмотренной выше модели взаимодействия были использованы RPCсредства в силу их достоинств, перечисленных в разделе 2.

Реализация включает в себя коммуникационный сервер (сервер сообщений), управляющий работой коммуникационной среды, и клиентную часть, обеспечивающую прикладным программам процедурный интерфейс к средствам взаимодействия.

Коммуникационный сервер регистрирует подключаемые к среде ПП, организует с ними каналы связи, диспетчеризует и распределяет сообщения. Коммуникационный сервер функционирует как фоновый процесс (демон, в терминологии ОС UNIX) на одном из узлов вычислительной сети.

Клиентная часть реализована в виде библиотеки объектных файлов функций языка программирования СИ, образующих процедурный интерфейс к средствам взаимодействия. Эта библиотека должна быть подключена при компоновке исполняемого файла прикладной программы.

Библиотека включает в себя функции (около 30) следующих пяти групп:

1. управления взаимодействием с коммуникационной средой (функции инициализации и разрушения связи, открытие/закрытие каналов);

2. манипулирования слотами тела сообщения;

3. создания/удаления приемников сообщений;

4. посылки сообщений в среду;

5. обработки запросов (функции посылки ответа, отказа от обработки запроса, задержки посылки ответа, повторной генерации отложенного запроса).

Тестирование разработанных средств было выполнено в локальных сетях на базе протоколов TCP/IP с использованием операционных систем SunOS 4.1 (ЭВМ SPARCstation), Ultrix 3.0 (ЭВМ mVAX II) и SunOS 5.2 (ЭВМ типа IBM PC и SPARCstation).

5. Использование средств взаимодействия Примером использования описанной технологии может служить распределенная система моделирования на базе программно-методического комплекса (ПМК) ПА8.

Распределенная система моделирования состоит из трех подсистем.

1. Решающее ядро ПМК ПА8 предназначено для моделирования и анализа сложных динамических объектов мехатроники во временной и частотной областях.

Исходной информацией для ПА8 служит описание объекта на текстовом входном языке. Результаты анализа в виде табличной зависимости фазовых переменных, описывающих состояние объекта, от времени (или частоты) представляются в алфавитно-цифровой форме.

2. Графический редактор схем (ГРС) предназначен для построения в интерактивном режиме изображений эквивалентных схем объектов анализа и автоматической генерации описаний этих объектов на текстовом входном языке ПМК ПА8.

3. Графический визуализатор (ГВ) предназначен для представления в графической форме табличных зависимостей, генерируемых ПМК ПА8.

Первоначально каждая из указанных подсистем создавалась для автономной работы и поддерживала обмен данными с другими подсистемами через файлы. Однако создание средств организации взаимодействия подсистем дало возможность обеспечить их совместную работу как на отдельной ЭВМ, так и в локальной вычислительной сети.

Были разработаны два следующих прикладных протокола:

Pages:     || 2 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.