5.8.2. Передача сообщений в распределенных системах

Единственным по-настоящему важным отличием распределенных систем от централизованных является способ взаимодействия процессов. Межпроцессное взаимодействие может осуществляться двумя способами [ 28 ]:

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

• путем передачи данных друг другу в виде сообщений.

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

В заголовке содержатся следующие элементы:

• адреса процесса-отправителя и процесса-получателя;

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

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

• поле типа данных, указывающее, какие данные (целые числа, строки символов и т. п.) передаются;

• поле длинны данных - определяет длину передаваемых в сообщении даных, т. е. размер поля сообщения;

• поле данных - содержит передаваемые данные.

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

В любой сетевой ОС имеется подсистема передачи сообщений, называемая транспортной подсистемой, которая имеет набор средств для организации взаимодействия процессов в сети. Назначение этой системы - экранировать детали сложных сетевых протоколов от программистов. Подсистема позволяет процессам взаимодействовать посредством достаточно простых примитивов. В самом простом случае системные средства обеспечения связи могут быть сведены к двум основным коммуникационным примитивам: один send (отправить), другой receive (получить) - для получения сообщения.

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

Транспортная подсистема сетевой ОС имеет сложную структуру, отражающую структуру семиуровневой модели взаимодействия открытых систем (Open System Interconnection, OSI). Представление сложной задачи сетевого взаимодействия компьютеров в виде иерархии частных задач позволяет организовать это взаимодействие максимально гибким образом. В это же время каждый уровень модели OSI экранирует особенности лежащих под ним уровней от вычисляющих уровней, что делает средства взаимодействия компьютеров все более универсальными по мере продвижения вверх по уровням. Таким образом, в процесс выполнения примитивов send и received вовлекаются средства всех нижележащих коммуникационных протоколов (рис. 5.25).

Несмотря на концептуальную простоту примитивов send и received, существуют различные варианты их реализации, от правильного выбора которых зависит эффективность работы сети.

Центральным вопросом взаимодействия процессов в сети является способ их синхронизации, который полностью определяется используемыми в ОС коммуникационными примитивами. В этом отношении коммуникационные примитивы делятся на блокирующие (синхронные) и неблокирующие (асинхронные), причем смысл данных терминов в целом соответствует смыслу аналогичных терминалов, применяемых при описании системных вызовов и операций ввода-вывода._

рис 5.25

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

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

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

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

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

• опрос (polling). Этот метод предусматривает наличие еще одного базового примитива test (проверить), с помощью которого процесс-получатель может анализировать состояние буфера;

• прерывание (interrupt). Этот метод использует программное прерывание для уведомления процесса-получателя о том, что сообщение помещено в буфер (хотя это и эффективно, но усложняет программирование).

При использовании блокирующего примитива send может возникнуть ситуация, когда процесс-отправитель блокируется навсегда. Например, если процесс-получатель потерпел крах или отправленное было утеряно из-за сетевой ошибки. Чтобы предотвратить такую ситуацию, блокирующий примитив send, часто используя механизм тайм-аута, завершается со статусом ≪ошибка≫ (это же относится к примитиву receive).

Если при взаимодействии двух процессов оба примитива - send и receive – являются блокирующими, говорят, что процессы взаимодействуют по сети синхронно, в противном случае взаимодействие асинхронное (рис. 5.26.).

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

рис 5.26