3. Распределенная обработка в сетевых ос

Межпроцессное взаимодействие в распределенных системах

Межпроцессное взаимодействие может осуществляться одним из двух способов:

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

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

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

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

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

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

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

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

Синхронизация

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

Коммуникационные примитивы могут быть оформлены в коммуникационные примитивы двумя способами: как внутренние процедуры ядра или как системные вызовы.

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

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

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

Синхронное взаимодействие является более простым, его легко реализовать, а так же оно более надёжно. Недостаток – ограниченный параллелизм и возможность возникновения клинчей.

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

Буферизация

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

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

ОС предоставляет для прикладных процессов специальный примитив для создания буферов сообщений. Часто такой буфер носит название порта (port), или почтового ящика (mailbox).

Способы адресации

Существует три способа адресации:

1. аппаратный. Используется аппаратный адрес сете­вых адаптеров. Такое использование сетевого адреса адаптера в качестве адреса получателя приводит к очень серьезному ограни­чению — на каждой машине должен выполняться только один процесс. Кроме того, сообщения можно передавать толь­ко в пределах одной локальной сети;

2. числовой. Наибольшее распространение получила система адресации, в которой адрес состоит из двух частей, определяющих компьютер и процесс, которому предназначено сообщение: machine_id@local_id. Для адресации процесса в этом способе применяется числовой идентификатор local_id, имеющий уникальное в пределах узла machine_id значение. Этот идентификатор может однозначно указывать на конкретный процесс, работающий на данном компьютере, то есть являться идентификатором типа process_id;

3. символьный. Для повышения прозрачности адресации требует создания в сети службы оперативного отображения символьных имен на числовые идентификаторы. Например, нотация URL (Universal Resource Locator). Если в сообщении указан адрес ftp://ark.bestcompany.ru/, то это означает, что оно отправлено службе ftp, работающей на компьютере ark.bestcompany.ru.

Символьные имена – это значительный шаг вперед, по сравнению с числовыми.

Надёжные и ненадёжные операции

Ранее подразумевалось, что когда отправитель посылает сообщение, адресат его обязательно получает. Но на практике сообщения могут теряться.

Существует три подхода для решения этой проблемы:

1. система не берёт на себя ни каких обязательств по поводу доставки сообщений – это дейтаграммный способ. Реализацией надёжного взаимодействия при его применении становится заботой прикладного программиста;

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

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

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

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

Для реализации примитивов с различной степенью надёжности передачи сообщений система обмена сообщениями ОС использует различные коммуникационные протоколы. Так, если сообщение передается через IP-сеть, то используется протокол транспортного уровня ТСР, обеспечивающий надежность. Если надежность не требуется, то используется протокол UDP.

Механизм Sockets

Механизм сокетов (sockets) впервые появился в версии 4.3 BSD UNIX. Позже он превратился в одну из самых популярных систем сетевого обмена сообщениями. Сегодня этот механизм реализован во многих ОС.

Универсальность Механизма сокетов обеспечивают следующие концепции:

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

2. использование абстрактной конечной точки соединения, называющейся сокет;

3. сокет может иметь как высокоуровневое символьное имя, как и низкоуровневое, отражающее специфику адресации отдельного коммуникационного домена;

4. для каждого коммуникационного домена могут существовать сокеты различных типов.

Для обмена сообщениями механизм сокетов предлагает следующие примитивы, реализованные как системные вызовы:

1. создание сокета:

s = socket (domain. type. protocol);

2. связывание сокета с адресом:

bind (s. addr. addrlen);

3. запрос на установление соединения с удаленным сокетом:

connect (s. server_addr. server_addrlen);

4. ожидание запроса на установление соединения:

listen (s. backlog);

5. принятие запроса на установление соединения:

snew = accept (s. client_addr. client_addrlen);

6. отправка сообщения по установленному соединению:

write (s. message. msg_len);

7. прием сообщения по установленному соединению:

nbytes = read (snew. buffer. amount);

8. отправка сообщения без установленного соединения:

sendto (s. message. receiver_address);

9. прием сообщения без установленного сообщения:

amount = recvfrom (s. message. sender_address).

Вызов удаленных процедур

Идея, положенная в основу RPC, состоит в том, чтобы вызов удаленной процедуры по возможности выглядел так же как и вызов локальной процедуры.

Механизм RPC достигает прозрачности следующим образом. Когда вызываемая процедура действительно является удаленной, а в библиотеку процедур вместо локальной реализации оригинального кода процедуры помещается другая версия процедуры – клиентский стаб (stub – заглушка). На удаленный компьютер, который выполняет роль сервера удаленных процедур, помещается оригинальный код вызываемой процедуры, а так же еще один стаб – серверный стаб. Стабы используют для передачи данных через сеть средства подсистемы обмена сообщениями.

Стабы могут генерироваться вручную и автоматически.

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

Автоматический способ основан на применении специального языка - языка определения интерфейса (Interface Definition Language, IDL). С помощью этого языка программист описывает интерфейс между клиентом и сервером RPC. Описание включает список имен процедур, выполнение которых клиент может запросить у сервера, а так же список типов аргументов и результатом этих процедур. Этой информации достаточно для выполнения стабами проверки типов аргументов и генерации вызывающей последовательности.

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

Механизм RPC оперирует двумя типами сообщений: сообщениями-вызовами и сообщениями-ответами, с помощью которых реализуется протокол RPC, определяющий способ взаимодействия клиента с сервером.

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

Идентификатор сообщения	Тип сообщения	Идентификатор клиента	Идентификатор удалённой процедуры			Аргументы
			Номер программы	Номер версии	Номер процедуры

Идентификатор сообщения

Тип сообщения

Статус ответа - ошибка

Результаты или причина ошибки

Рисунок 1.2 – Формат сообщений RPC

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

Процедура, устанавливающая соответствие между клиентом и сервером RPC, называется связывание (binding). Методы связывания применяемые в различных реализациях RPC, отличаются:

1. способом задания сервера, с которым хотел бы быть связан клиент;

2. способом обнаружения сетевого адреса требуемого сервера процессом связывания;

3. стадией, на которой происходит связывание.

В наиболее простом случае имя или адрес сервера RPC задается в явной форме, в качестве аргумента клиентского стаба или программы-сервера, реализующей интерфейс определенного типа. Основной недостаток такого подхода – отсутствие гибкости и прозрачности. При перемещении сервера или при существовании нескольких серверов клиентская программа не может автоматически выбирать новый или наименее загруженный в данным момент сервер. Этот способ из-за своей простаты часто используется на практике. Такой метод связывания можно назвать полностью статическим.

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

1. типа интерфейса;

2. экземпляра интерфейса.

Следовательно, это более гибкий метод – клиент импортирует интерфейс, а сервер его экспортирует.

В случае, когда для клиента важен только тип интерфейса, процесс обнаружения требуемого сервера в сети с экземпляром интерфейса определенного типа может быть простроен двумя способами:

1. с использованием широковещания;

2. с использованием централизованного агента связывания.

Первый способ основан на широковещательном распространении по сети серверами RPC имени своего интерфейса, включая и адрес экземпляра.

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

Недостатки динамического связывания – дополнительные накладные расходы на экспорт и импорт интерфейсов. Кроме того, в больших распределенных системах может стать узким местом агент связывания, и тогда необходимо использовать распределенную систему агентов, что можно сделать стандартным способом (NDS, X.500, LDAP).

При использовании статического связывания часть адреса, как порт сервера интерфейса определяется клиентом динамически. Эту процедуру поддерживает специальный модуль RPCRuntime, называемой в ОС UNIX модулем отображения портов (portmapper), а в ОС семейства Windows - локатором RPC (RPC Locator). Этот модель работает на каждом сетевом узле, поддерживающем механизм RPC, и доступен по порту TCP/UDP. Но область действий этого механизма ограничивается портом одного компьютера.