Средства взаимодействия процессов в сетях ЭВМ
Обмен сообщениями между процессами является основой межпроцессного взаимодействия в распределенной системе. В то же время стандартные средства связи между процессами локальных и сетевых операционных систем не скрывают взаимодействия процессов, то есть не обеспечивают прозрачность доступа.
В настоящее время существует четыре способа связи между процессами, работающими на разных ЭВМ:
1. Удаленный вызов процедур;
2. Обращение к удаленным объектам;
3. Связь посредством сообщений;
4. Связь на основе потоков данных.
Рассмотрим последовательно каждый из этих видов связи между процессами.
1. УДАЛЕННЫЙ ВЫЗОВ ПРОЦЕДУР
В любом языке программирования существует понятие процедуры. Процедура - это стандартно оформленный программный модуль, доступный для использования другими программами с помощью стандартных операций вызова процедур. Стандартные операции вызова процедур предусматривают передачу в процедуру исходных параметров для ее работы и возврат в вызывающую программу результатов работы процедуры. В локальной ЭВМ передача в процедуру исходных параметров для ее работы и возврат в вызывающую программу результатов работы процедуры производится через стек. Стек - специализированная область оперативной памяти ЭВМ, доступ к которой производится не по адресу (номеру) ячейки, а по очередности поступления в стек информации в соответствии с принципом FILO (First In, Last Out - первый пришел, последний вышел). В локальной ЭВМ передача параметров между вызывающей программой и процедурой происходит тремя способами:
1. Передача по значению - применяется при обмене отдельными переменными, когда в стек помещаются их непосредственные значения;
2. Передача по ссылке - применяется при обмене массивами данных, когда в стек помещаются начальные адреса (ссылки) массивов данных;
3. Передача через копирование-восстановление - применяется при необходимости модификации процедурой передаваемых ей переменных и возврата в вызывающую программу их новых значений. При вызове процедуры производится копирование переменной в стек, а при возврате в вызывающую программу - считывание нового значения этой переменной из стека и замена старого значения переменной в оперативной памяти на новое.
Удаленный вызов процедур подразумевает выполнение процедуры на другой ЭВМ сети, что делает невозможным передачу данных через стек.
Проблемы при выполнении удаленных процедур возникают вследствие следующих факторов:
1. Вызывающая программа и удаленная процедура размещаются на разных ЭВМ и выполняются в различных адресных пространствах;
2. Существует разница в представлении данных при размещении вызывающей программы и удаленной процедуры на ЭВМ с различными форматами данных;
3. Возможно возникновение сбоев на обеих ЭВМ в процессе выполнения удаленной процедуры.
Удаленный вызов процедур осуществляется с помощью технологии RPC (Remote Procedure Call - удаленный вызов процедур). Идея RPC состоит в том, чтобы с точки зрения пользователя (программиста) удаленный вызов процедур выглядел точно так же, как локальный. Это означает, что ни программист, ни вызывающая программа не должны уведомляться о том, что вызываемая процедура выполняется на другой ЭВМ, и наоборот, вызываемая процедура не должна уведомляться о том, что она вызывается программой, физически размещенной на другой ЭВМ сети. Иными словами, RPC призвана обеспечить прозрачность местоположения. RPC организует прозрачность местоположения с помощью механизмов клиентской и серверной заглушек. Клиентская заглушка - специальная версия функции вызова процедуры, работающая на стороне клиента и подменяющая аналогичную стандартную локальную функцию в случае размещения нужной процедуры на другой ЭВМ сети. Клиентская заглушка вызывается стандартной операцией вызова процедуры, но в отличие от оригинальной локальной функции вызова процедуры, она не помещает данные в стек, а упаковывает их в сообщение и требует у операционной системы переслать это сообщение на сервер.
При поступлении сообщения на сервер операционная система сервера передает его серверной заглушке. Серверная заглушка - специальная версия функции вызова процедуры, работающая на стороне сервера и подменяющая аналогичную стандартную локальную функцию в случае поступления по сети запроса на вызов удаленной процедуры, физически размещенной на данном сервере. Серверная заглушка преобразует приходящий по сети запрос в стандартный вызов локальной процедуры с передачей параметров через стек.
Таким образом, ни вызывающая программа, ни вызываемая процедура не уведомляются о том, что они физически находятся на различных ЭВМ сети. Удаленный вызов процедур происходит в десять этапов:
1. Вызывающая программа клиента стандартным образом вызывает клиентскую заглушку;
2. Клиентская заглушка создает сообщение и вызывает операционную систему рабочей станции;
3. Операционная система рабочей станции пересылает сообщение на сервер;
4. Операционная система сервера передает сообщение серверной заглушке;
5. Серверная заглушка извлекает из сообщения параметры и стандартным образом выполняет вызов процедуры;
6. После окончания своей работы процедура возвращает результаты серверной заглушке;
7. Серверная заглушка создает сообщение и вызывает операционную систему сервера;
8. Операционная система сервера пересылает сообщение на рабочую станцию;
9. Операционная система рабочей станции передает сообщение клиентской заглушке;
10. Клиентская заглушка извлекает из сообщения параметры и стандартным образом возвращает их вызывающей программе.
Базовая модель RPC предполагает, что вызывающий и вызываемый процессы связываются друг с другом для обмена сообщениями по сети ЭВМ. Однако существует вариант, когда клиент и сервер работают на одной машине. В стандартном случае в этом варианте применяются средства локального межпроцессного взаимодействия, имеющиеся во всех локальных операционных системах, поддерживающих многопрограммный режим.
Ряд локальных операционных систем предоставляют процессам, размещенным на одной ЭВМ, эквивалент RPC под названием "doors".
В стандартном варианте вызова клиентом удаленной процедуры его работа приостанавливается до получения ответа. Такая приостановка работы клиентского процесса до получения ответа от удаленной процедуры называется блокировкой процесса, а вызов процедуры, соответственно, синхронным вызовом процедур.
В ряде случаев для продолжения работы клиентского процесса ответ не нужен (например, добавление записи в базу данных, запуск удаленной службы и т. д.). Технология RPC предоставляет средства асинхронного вызова процедур, когда клиент получает возможность продолжить свою работу сразу после выполнения запроса на удаленный вызов процедуры. Для этого сервер немедленно по приходу запроса отсылает клиенту квитанцию о приеме запроса и только после этого вызывает запрашиваемую процедуру.
В случае, когда ответ необходим, но его отсутствие не влияет на продолжение работы клиентского процесса (например, циклические процессы в АСУ), организуются два асинхронных вызова: один - запрос со стороны клиента, а другой - ответ со стороны сервера. Комбинация из двух асинхронных вызовов называется отложенным синхронным вызовом процедур.
Дальнейшим развитием технологии RPC является система DCE RPC (Distributed Computing Environment - среда распределенных вычислений), адаптированная к программному обеспечению фирмы Microsoft. В настоящее время существуют версии DCE RPC для всех распространенных операционных систем.
2. ОБРАЩЕНИЕ К УДАЛЕННЫМ ОБЪЕКТАМ
С появлением объектно-ориентированного программирования стало очевидно, что принципы технологии RPC могут быть равно применимы и к программным объектам.
Программный объект - это стандартно оформленный программный модуль, содержащий данные и операции над этими данными. Данные, содержащиеся в объекте, в программировании называются состоянием объекта, а операции над этими данными - методами объекта. Доступ к методам можно получить через интерфейс объекта, предоставляемый системами программирования. Объект может реализовывать множество интерфейсов. В свою очередь, для описания интерфейса также может существовать несколько объектов.
Объекты в распределенных системах существуют в формах, принятых в том или ином языке программирования. Как правило, при выполнении распределенных вычислений интерфейс объекта находится на другой ЭВМ, чем сам объект. Такой объект называется распределенным объектом. При этом состояние объекта (т.е. содержащиеся в объекте данные) никогда не распределяется, а локализовано на одной ЭВМ. С других ЭВМ доступны только интерфейсы, реализованные в объекте.
При обращении клиента к распределенному объекту управление передается программе реализации интерфейса объекта, аналогичной клиентской заглушке и называемой заместителем. Заместитель осуществляет транзит параметров объекта от вызывающей программы к операционной системе рабочей станции и обратно, так же как это делает клиентская заглушка.
На стороне сервера транзит параметров от операционной системы сервера к методам объекта и обратно осуществляет аналог серверной заглушки, называемый программа-скелетон.
В зависимости от степени связи со своим сервером объекты в распределенных системах могут быть сохранными (или резидентными) и нерезидентными. Сохранный объект продолжает существовать вне зависимости от состояния своего сервера. Сервер, управляющий таким объектом, может сохранить состояние объекта в оперативной памяти и завершить свою работу. Позже вновь запущенный сервер считывает состояние объекта из памяти и передает ему управление. Нерезидентный объект существует, только пока сервер им управляет. При завершении работы сервера объект выгружается из оперативной памяти.
Для привязки клиента к объекту, последние предоставляют ссылки, уникальные в пределах распределенной системы. Ссылка на объект должна содержать:
1. Сетевой адрес ЭВМ, на которой физически размещен программный объект;
2. Адрес сервера, который управляет этим объектом;
3. Указание на конкретный объект.
При возникновении сбоя на серверной ЭВМ и последующей её перезагрузке серверный процесс может загрузиться в другое место оперативной памяти. При этом все ссылки на объекты станут неправильными. Для решения данной проблемы необходимо создать сервер локализации, постоянно следящий за работой серверов, на которых размещены объекты. Сервер локализации требует указания в ссылке на объект не адреса, а уникального идентификатора объекта.
После того, как клиент свяжется с объектом, он может через заместителя обратиться к методам объекта. Такое удаленное обращение к методам поддерживается технологией RMI (Remote Method Invocation - удаленное обращение к методам). Технология RMI поддерживает два способа удаленного обращения к методам:
1. Статическое обращение, когда интерфейсы объекта при разработке клиентской прикладной программы заранее известны;
2. Динамическое обращение, когда сами методы и параметры обращения к ним выбираются в процессе выполнения прикладной программы.
Обращение к удаленным объектам может производиться как с использованием непосредственно самой технологии RMI, так и с использованием системы DCE RPC.
При обращении RMI клиент использует ссылку, содержащую следующие параметры:
1. Сетевой адрес сервера;
2. Полный путь к объекту на сервере;
3. Локальный идентификатор объекта в адресном пространстве сервера;
4. Указание на стек протоколов, используемых для взаимодействия клиента и сервера.
При обращении DCE RPC клиент передает серверу следующие данные:
1. Идентификатор объекта;
2. Идентификатор интерфейса, содержащего метод;
2. Идентификатор самого метода;
3. Параметры.
Сервер поддерживает таблицу объектов, с помощью которой по полученной информации идентификаторов объекта и интерфейса, идентифицирует объект, к которому обратился клиент. Затем сервер выбирает запрошенный метод и передает ему параметры. При получении сервером запроса с обращением к объекту, выполняются следующие действия:
1. Операционная система сервера передает запрос соответствующему адаптеру объектов;
2. Адаптер объекта извлекает из запроса ссылку на объект и передает запрос скелетону соответствующего объекта в соответствии с его политикой активизации.
3. Скелетон выполняет транзит параметров объекта и обращается к соответствующему методу объекта.
3. СВЯЗЬ ПОСРЕДСТВОМ СООБЩЕНИЙ
Связь посредством сообщений применяется при необходимости передачи данных без их обработки на сервере (напр.: электронная почта). При осуществлении распределенной обработки информации, связь посредством сообщений является основным способом связи между процессами, размещенными на различных ЭВМ. Классификация связи посредством сообщений:
1. По виду используемой коммуникации:
а) Сохранная (резидентная) связь посредством сообщений. При этом виде связи используется коммуникация, ориентированная на установление соединения. Отправитель не контролирует состояние процесса-получателя в момент отправки сообщения. В то же время, сообщение не будет потеряно и будет доставлено процессу-получателю сразу, как только он будет готов его принять;
б) Нерезидентная связь посредством сообщений. При этом виде связи используется коммуникация, не ориентированная на установление соединения. Сообщение существует в системе только в момент его передачи процессомотправителем. Если по какой-либо причине процесс-получатель не имеет возможности принять сообщение, оно теряется;
2. По виду блокировки процесса-отправителя:
а) Синхронная связь посредством сообщений. При этом виде связи процесс-отправитель блокируется до получения ответа от процесса-получателя о приеме сообщения;
б) Асинхронная связь посредством сообщений. При этом виде связи процесс-отправитель продолжает свою работу, не дожидаясь квитанции от процесса-получателя.
В системах нерезидентной связи посредством сообщений применяется стандарт пересылки сообщений MPI (Message Passing Interface - связь посредством сообщений), основанный на сокетах Беркли. Сокет Беркли - это абстрактная конечная точка коммуникации, в которую прикладная программа записывает данные, необходимые для передачи по сети, и из которой она может считывать поступающую из сети информацию. Сокеты Беркли были впервые реализованы в версии операционной системы UNIX, разработанной в университете Беркли. Операционная система предоставляет прикладной программе набор команд, называемых примитивами, с помощью которых прикладная программа может создать сокет, назначить ему локальный адрес, переслать или принять данные и разорвать соединение.
В системах сохранной связи посредством сообщений прикладная программа помещает отправляемое сообщение в локальную исходящую очередь, находящуюся на той же ЭВМ. Сообщение, помещенное в очередь, содержит описание очереди назначения, в которую оно должно быть перемещено. Системный процесс-отправитель помещает сообщение в очередь на коммуникационном сервере (маршрутизаторе), и оно перемещается последовательно по цепочке коммуникационных серверов до места назначения. Сообщение будет храниться в очереди последнего в цепочке маршрутизатора до тех пор, пока процесс-получатель не будет готов его принять. Процесс-отправитель в состоянии гарантировать только попадание сообщения во входящую очередь процесса-получателя. Будет ли это сообщение прочитано, определяется целиком поведением процесса-получателя. Очереди управляются программами, называемыми менеджеры очередей. Они взаимодействуют непосредственно с отправляющими и принимающими сообщения прикладными программами. Важнейшей областью применения очередей сообщений является интеграция существующих и новых прикладных программ в единые согласованные распределенные информационные системы. Интеграция требует, чтобы отправляемые сообщения имели единый формат внутри одной системы. Функции представительного уровня модели OSI в распределенной информационной системе выполняет специальная программа, называемая брокер сообщений. Брокер сообщений работает как шлюз прикладного уровня в системе очередей сообщений, осуществляя преобразование входящих сообщений в формат целевой прикладной программы. Основой брокера сообщений является база данных с правилами перекодировки сообщений из одного формата в другой.
4. СВЯЗЬ НА ОСНОВЕ ПОТОКОВ ДАННЫХ
Рассмотренные ранее способы связи между процессами, работающими на разных ЭВМ, касались обмена более или менее независимыми, законченными порциями информации, не привязанными к реальному времени (параметры процедур и объектов, сообщения). Однако в прикладных программах реального масштаба времени (аудио и видео) временные характеристики имеют решающее значение (аудио- и видеопотоки).
Для обмена критичной ко времени передачи информацией распределенные системы предоставляют поддержку потоков данных. Классификация потоков данных:
1. По физическому содержанию потока:
а) Дискретный поток данных - поток байт;
б) Непрерывный поток данных - поток бит;
2. По информационному содержанию потока:
а) Простой поток данных - содержит только одну последовательность данных;
б) Комплексный поток данных - содержит несколько связанных между собой простых потоков, называемых вложенными потоками данных (напр.: видео со стереозвуком).
Различают три режима передачи потоков данных:
1. Асинхронный режим передачи. В асинхронном режиме передачи временные ограничения на передачу потока данных не накладываются;
2. Синхронный режим передачи. В синхронном режиме передачи для каждого элемента потока данных определяется максимально возможная задержка передачи. Этот режим используется там, где необходимо передавать данные не реже какого-либо промежутка времени - например, при измерении параметров;
3. Изохронный режим передачи. В изохронном режиме передачи для каждого элемента данных определяется как максимально возможная, так и минимально возможная задержка передачи. Этот режим используется там, где недопустимо ни замедление ни ускорение передачи данных - например, при передаче аудио- и видеопотоков. Интервал времени между минимально возможной и максимально возможной задержками передачи называется интервалом дрожания.
Временные зависимости потоков данных выражаются в виде требований к качеству обслуживания, описывающих, что должна сделать распределенная система для того, чтобы гарантировать сохранение в потоке данных заданных временных соотношений. Требования к качеству обслуживания закрепляются в документе, называемом спецификация передачи. Спецификация передачи входит в пакет протоколов транспортного уровня модели OSI.
Для передачи потока данных распределенная система должна захватить ресурсы, удовлетворяющие требованиям к качеству обслуживания. Обычно такими ресурсами являются:
1. Пропускная способность каналов связи;
2. Буферная память маршрутизаторов;
3. Вычислительная мощность узлов обработки данных.
В мультимедийных системах важное значение имеет взаимная синхронизация вложенных потоков данных, т.е. поддержание между ними строгих временных соотношений. Различают два типа синхронизации вложенных потоков данных:
1. Простейшая синхронизация. Этот вид синхронизации осуществляется между дискретным и непрерывным потоками данных (напр.: показ слайдов со звуковым сопровождением);
2. Синхронизация артикуляции. Синхронизация артикуляции осуществляется между непрерывными потоками данных. Этот термин пришел в вычислительную технику из кинематографа, где означал синхронизацию движений губ актера с произносимыми им звуками. Примером синхронизации артикуляции может быть звуковое сопровождение любого видеофильма. Для того, чтобы визуально губы актера двигались в такт произносимым им словам, рассинхронизация артикуляции не должна превышать 20 мс.
Наиболее просто синхронизация вложенных потоков данных достигается путем их взаимного мультиплексирования (напр.: стандарт MPEG - Motion Picture Expert Group).