Механизм передачи сообщений в распределенных системах

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

□ с помощью совместного использования одних и тех же данных (разделяемая память);

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

В централизованных системах связь между процессами, как правило, предпола­гает наличие разделяемой памяти. Типичный пример — задача «поставщик-по­требитель». В этом случае один процесс пишет в разделяемый буфер, а другой читает из него. Даже наиболее простая форма синхронизации — семафор — тре­бует, чтобы хотя бы одно слово (переменная самого семафора) было разделяе­мым. Аналогичным образом происходит взаимодействие не только между пользо­вательскими процессами, но и между приложением и операционной системой — процесс в пользовательском режиме запрашивает у ОС выполнения некоторой операции с помощью системного вызова, помещая в доступную ему часть опера­тивной памяти параметры этого системного вызова (например, имя файла, сме­щение от его начала и количество байт, которые необходимо прочитать). После этого модуль ядра ОС считывает эти параметры из пользовательской памяти (ядру в привилегированном режиме доступна вся память, как ее системная часть, так и пользовательская) и выполняет системный вызов. Взаимодействие и в этом слу­чае происходит за счет непосредственно доступной обоим участникам области памяти.

В распределенных системах не существует памяти, непосредственно доступной процессам, работающим на разных компьютерах, поэтому взаимодействие про­цессов (как находящихся в пользовательской фазе, так и в системной, то есть выполняющих код операционной системы) может осуществляться только путем передачи сообщений через сеть. Как было показано в разделе «Сетевые службы и сетевые сервисы» главы 2 «Назначение и функции операционной системы», на основе механизма передачи сообщений работают все сетевые службы, предостав­ляющие пользователям сети разнообразные услуги — доступ к удаленным файлам, принтерам, почтовым ящикам и т. п. В сообщениях переносятся запросы от кли­ентов некоторой службы к соответствующим серверам — например, запрос на просмотр содержимого определенного каталога файловой системы, расположен­ной на сетевом сервере. Сервер возвращает ответ — набор имен файлов и подка­талогов, входящих в данный каталог, также помещая его в сообщение и отправ­ляя его по сети клиенту.

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

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

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

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

□ Структурированная информация, состоящая в общем случае из нескольких частей: поля типа данных, поля длины данных и поля значения данных (то есть собственно данных). Поле типа данных определяет, например, что дан­ные являются целым числом или же представляют собой строку символов (это поле может также содержать признак нерезидентности данных, то есть указатель на данные, которые хранятся где-то вне данного сообщения). Вто­рое поле определяет длину передаваемых в сообщении данных (обычно в бай­тах), то есть размер следующего поля сообщения. Сообщение может включать несколько элементов, состоящих из описанных трех полей. В тех случаях, ко­гда сообщение всегда переносит данные одного и того же типа, поле типа может быть опущено. То же касается поля длины данных — для тех типов со­общений, которые переносят данные фиксированного формата, но такая си­туация характерна только для протоколов низкого уровня (например, ATM, имеющего фиксированный размер поля данных в 48 байт).

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

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

Несмотря на концептуальную простоту примитивов send и receive, существуют различные варианты их реализации, от правильного выбора которых зависит эф­фективность работы сети. В частности, эффективность зависит от способа зада­ния адреса получателя. Не менее важны при реализации примитивов передачи сообщений ответы и на другие вопросы. В сети всегда имеется один получатель или их может быть несколько? Требуется ли гарантированная доставка сообще­ний? Должен ли отправитель дождаться ответа на свое сообщение, прежде чем продолжать свою работу? Как отправитель, получатель и подсистема передачи сообщений должны реагировать на отказы узла или коммуникационного канала во время взаимодействия? Что нужно делать, если приемник не готов принять сообщение, нужно ли отбрасывать сообщение или сохранять его в буфере? А если сохранять, то как быть, если буфер уже заполнен? Разрешено ли приемнику из­менять порядок обработки сообщений в соответствии с их важностью? Ответы на подобные вопросы составляют семантику конкретного протокола, передачи сообщений.