Технология организации взаимодействия параллельно выполняющихся программ в сетях ЭВМ

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

Технология организации взаимодействия параллельно выполняющихся программ в сетях ЭВМ Данное пособие содержит описание технологии организации взаимодействия прикладных программ, параллельно функционирующих на различных узлах вычислительной сети в среде ОС 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.0 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. Первоначально каждая из указанных подсистем создавалась для автономной работы и поддерживала обмен данными с другими подсистемами через файлы. Однако создание средств организации взаимодействия подсистем дало возможность обеспечить их совместную работу как на отдельной ЭВМ, так и в локальной вычислительной сети. Были разработаны два следующих прикладных протокола: 1. взаимодействия ПМК ПА8 и ГВ для обеспечения возможности построения графиков фазовых переменных непосредственно в ходе расчета; 2. взаимодействия ГРС и ПА8 для обеспечения возможности пользователю, работающему с ГРС, модифицировать численные значения параметров анализируемого объекта непосредственно в ходе расчета. Таким образом пользователь распределенной системы получил возможность оперативно "оптимизировать" численные значения параметров объектов проектирования, без задержки наблюдая результат своих изменений в окне ГВ. Возможность выполнения параллельно функционирующих ГРС, ПА8 и ГВ на различных узлах ЛВС обеспечивает рациональное использование вычислительных ресурсов сети и повышает "реактивность" системы.