Сети -> TCP/IP -> Протоколы сетевого взаимодействия TCP/IP

Московский Государственный Технический Университет

имени Н.Э.Баумана

Кафедра САПР

---

Федорук В.Г.

rk6fed@wwwcdl.bmstu.ru

263-65-26

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

Данное пособие содержит описание технологии организации взаимодействия прикладных программ, параллельно функционирующих на различных узлах вычислительной сети в среде ОС 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 и ГВ на различных узлах ЛВС обеспечивает рациональное использование вычислительных ресурсов сети и повышает "реактивность" системы.