сохранной асинхронной связи

Распределенные системы
Тема презентации: Связь
Выолнил: ст.Вовк Е. А.
гр ТИ-42м
1
Связь
Связь между процессами — это суть распределенных
систем. Нет смысла изучать распределенные системы, не
рассматривая при этом во всех подробностях способы
обмена информацией между различными процессами,
выполняющимися на разных машинах. Взаимодействие в
распределенных системах всегда базируется на
низкоуровневом механизме передачи сообщений,
предоставляемом базовой сетью.
2
1.1 Уровни протоколов
 Открытая система – это система, которая способна
взаимодействовать с любой другой открытой системой по стандартным
правилам, определяющим формат, содержимое и смысл отправляемых
и принимаемых сообщений.
 Чтобы упростить работу с множеством уровней и понятий,
используемых в передаче данных, международная организация по
стандартам (International Standards Organization, ISO) разработала
эталонную модель, которая ясно определяет различные уровни, дает
им стандартные имена и указывает, какой уровень за что отвечает.
 Модель OSI разрабатывалась для того, чтобы предоставить
открытым системам возможность взаимодействовать друг с другом.
Открытая система способна взаимодействовать с любой другой
открытой системой по стандартным правилам, определяющим формат,
содержимое и смысл отправляемых и принимаемых сообщений. Эти
правила зафиксированы в том, что называется протоколами (protocols).
3
1.1 Уровни протоколов
Для того чтобы группа компьютеров могла поддерживать связь по сети, они
должны договориться об используемых протоколах. Все протоколы делятся на
два основных типа. В протоколах с устаповлением соединения (connectionoriented) перед началом обмена данными отправитель и получатель должны
установить соединенрш и, возможно, договориться о том, какой протокол они
будут использовать. Протоколов без установления соединения (connectionless)
никакой подготовки не нужно.
4
1.1.1 Низкоуровневые протоколы
Физический уровень

Физический уровень ответственен за передачу нулей и единиц.
Сколько вольт использовать для передачи нуля или единицы, сколько
бит в секунду можно передать и можно ли осуществлять передачу
одновременно в двух направлениях — вот основные задачи
физического уровня. Кроме того, к физическому уровню относится
размер и форма сетевых коннекторов (разъемов), а также число
выводов и назначение каждого из них.

Протоколы физического уровня отвечают за стандартизацию
электрических, механических и сигнальных интерфейсов, чтобы, если
одна машина посылает ноль, другая приняла его как ноль, а не как
единицу.
5
1.1.1 Низкоуровневые протоколы
Канальный уровень

Физический уровень только пересылает биты. Пока нет ошибок, все
хорошо. Однако в реальных сетях происходят ошибки, и их нужно както находить и исправлять. Это и является главной задачей канального
уровня. Он группирует биты в модули, обычно называемые кадрами
(frames), и следит за тем, чтобы каждый кадр был передан правильно.

Канальный уровень делает это путем помещения специальной
битовой маски в начало и конец каждого кадра для их маркировки, а
также путем вычисления контрольной суммы (checksum), то есть
суммирования всех байтов кадра определенным образом. Канальный
уровень добавляет контрольную сумму к кадру. Когда кадр
принимается, приемник повторно вычисляет контрольную сумму данных
и сравнивает результат с контрольной суммой, пришедшей вместе с
кадром. Если они совпадают, кадр считается верным и принимается.
Если они различны, получатель просит отправителя снова отправить
этот кадр. Кадры последовательно нумеруются с указанием номеров в
заголовке, так что все понимают, где какой кадр.
6
1.1.1 Низкоуровневые протоколы
Сетевой уровень
Основной задачей сетевого уровня является задача выбора
наилучшего пути, которая называется маршрутизацией (routing).
В настоящее время, вероятно, наиболее широко распространенным
сетевым протоколом не требующий установления соединения является
IP, входящий в комплект протоколов Интернета. На сетевом уровне
сообщение именуется термином пакет (packet). IP-пакет может быть
послан без какой-либо предварительной подготовки. Маршрут каждого
из IP-пакетов до места назначения выбирается независимо от других
пакетов. Никакие внутренние пути не выбираются заранее и не
запоминаются.
7
1.1.2 Трансортные протоколы

Транспортный уровень — это последняя часть того, что называют
базовым стеком сетевых протоколов, поскольку в нем реализованы все
службы, которые необходимы для построения сетевых приложений и
которые не вошли в интерфейс сетевого уровня. Другими словами,
транспортный уровень дает возможность разработчикам приложений
использовать базовую сеть, лежащую в его основе.

На пути от отправителя к получателю пакеты могут теряться. В то
время как одни приложения задействуют собственные процедуры
исправления ошибок, другие предпочитают надежную связь.
Предоставить им эту службу — дело транспортного уровня. Идея
состоит в том, что приложение должно быть в состоянии передать
сообщение транспортному уровню и ожидать того, что оно будет
доставлено без потерь.
8
1.1.2 Трансортные протоколы

Транспортный протокол для интернета называется протоколом
управления передачей (Transmission Control Protocol, TCP). Комбинация
TCP/IP в настоящее время является стандартом при сетевых
взаимодействиях. Комплект протоколов Интернета также включает в
себя не требующий соединения транспортный протокол под названием
UDP (Universal Datagram Protocol — универсальный протокол
датаграмм), который, по сути, представляет собой IP с некоторыми
небольшими дополнениями. Пользовательские программы, не
нуждающиеся в протоколе с соединениями, обычно используют UDP.

Время от времени предлагаются дополнительные транспортные
протоколы. Так, например, для поддержки передачи данных в реальном
времени был определен транспортный протокол реального времени
(Real-time Transport Protocol, RTP). RTP — это кадровый протокол,
который определяет формат пакета для данных реального времени,
ничего не говоря о механизмах гарантированной доставки этих данных.
Кроме того, в нем определен протокол для мониторинга и управления
передачей RTP-пакетов.
9
1.1.3 Протоколы верхнего уровня
Сеансовый уровень
 Сеансовый уровень представляет собой фактически расширенную
версию транспортного уровня. Он обеспечивает управление диалогом,
отслеживая и запоминая, какая сторона говорит в настоящий момент, и
предоставляет средства синхронизации.
 Последние требуются для создания пользователями контрольных
точек при длинных сеансах передачи данных, а также уведомления их
о сбое в ходе такого сеанса. При этом необходимо сделать откат только
до последней контрольной точки и не нужно проходить весь путь
сначала. На практике сеансовый уровень нужен немногим приложениям
и поддерживается редко.
10
1.1.3 Протоколы верхнего уровня
Прикладной уровень
Прикладной уровень модели OSI изначально должен был содержать
набор стандартных сетевых приложений, например для работы с
электронной почтой, передачи файлов и эмуляции терминала. В
настоящее время он стал местом собрания всех приложений и
протоколов, которые не удалось пристроить ни на один из более низких
уровней. В эталонной модели OSI все распределенные системы
являются просто приложениями.
11
1.2 Обращение к удаленным обьектам
Объектно-ориентированная технология показала свое значение при
разработке распределенных приложений. Одним из наиболее важных
свойств объекта является то, что он скрывает свое внутреннее строение
от внешнего мира посредством строго определенного интерфейса.
Такой подход позволяет легко заменять или изменять объекты,
оставляя интерфейс неизменным.
12
1.2.1 Распределенные обьекты

Ключевая особенность объекта состоит в том, что он инкапсулирует
данные, называемые состоянием (state), и операции над этими
данными, называемые методами (methods). Доступ к методам можно
получить через интерфейс.

Важно понять, что единственным правильным способом доступа
или манипулирования состоянием объекта является использование
методов, доступ к которым осуществляется через интерфейс этого
объекта.

Это подразделение на интерфейсы и объекты, реализующие их,
очень важно для распределенных систем. Четкое разделение позволяет
нам помещать интерфейс на одну машину при том, что сам объект
находится на другой.
13
1.2.1 Распределенные обьекты
Скелетон – серверная заглушка
1. Когда клиент выполняет
привязку к распределенному
объекту, в адресное пространство
клиента загружается реализация
интерфейса объекта, называемая
заместителем (роху).
2 .Сами объекты находятся на
сервере и предоставляют
необходимые клиентской машине
интерфейсы. Входящий запрос на
обращение к методу сначала
попадает на серверную заглушку,
часто именуемую скелетоном
(skeleton).
3. Скелетон преобразует его в
правильное обращение к методу
через интерфейс объекта,
находящегося на сервере.
Серверная заглушка также
отвечает за маршалинг параметров в
ответных сообщениях и их
пересылку заместителю клиента.
14
1.2.2 Привязка клиента к обьекту

Системы поддерживающие распределенные объекты, обычно
предоставляют ссылки на объекты, уникальные в пределах системы.
Такие ссылки могут свободно передаваться между процессами,
запущенными на различных машинах.

Когда процесс хранит ссылку на объект, перед обращением к
любому из методов объекта процесс должен в первую очередь
выполнить привязку к этому объекту. Результатом привязки будет
заместитель, размещаемый в адресном пространстве процесса и
реализующий интерфейс с методами, к которым обращается процесс.
Во многих случаях привязка осуществляется автоматически. Когда
базовая система получает ссылку на объект, ей требуется способ
отыскать сервер, управляющий этим объектом, и поместить заместителя
в адресное пространство клиента.
15
1.2.2 Привязка клиента к обьекту
Реализация ссылок на обьекты
Иногда включают в ссылку на объект дескриптор реализации
(implementation handle), указывающий на полную реализацию заместителя.
Эту реализацию клиент может динамически загрузить при привязке к
объекту. Например, дескриптор реализации может принимать вид URLадреса, указывающего на файл архива :
ftp://ftp.clientware.org/proxies/java/proxy-v1.1a.zip.
Протокол привязки в этом случае будет нужен только для указания на
то, что данный файл следует динамически загрузить, разархивировать,
установить, а впоследствии создать экземпляр. Плюс такого подхода состоит
в том, что клиент не должен заботиться о том, доступна ли реализация
данного протокола. Кроме того, это дает разработчику объекта полную
свободу в разработке специфических для объекта заместителей.
16
1.2.3 Статическое и динамическое
обращение к методам

После того как клиент свяжется с объектом, он может через заместителя
обратиться к методам объекта. Подобное удаленное обращение к методам
называется - RMI (Remote Method Invocation).

Стандартный способ поддержки RMI — описать интерфейсы объектов на
языке определения интерфейсов. Такой подход к применению
предопределенных определений интерфейсов часто называют статическим
обращением (static invocation). Статическое обращение требует, чтобы
интерфейсы объекта при разработке клиентского приложения были
известны. Также оно предполагает, что при изменении интерфейса
клиентское приложение перед использованием новых интерфейсов будет
перекомпилировано.

В качестве альтернативы обращение к методам может осуществляться
более динамичным образом. В частности, иногда удобнее собрать параметры
обращения к методу во время исполнения. Этот процесс известен под
названием динамического обращения (dynamic invocation). Основное его
отличие от статического обращения состоит в том, что во время выполнения
приложение выбирает, какой метод удаленного объекта будет вызван.
17
1.2.3 Статическое и динамическое
обращение к методам
Динамическое обращение обычно выглядит следующим образом:
Invoke (object. method. input_parameters. output_parameters):

Здесь object идентифицирует распределенный объект; method —
параметр, точно задающий вызываемый метод; input_parameters —
структура данных, в которой содержатся значения входных параметров
метода; output_parameters — структура данных, в которой хранятся
возвращаемые значения.

Область применения динамических обращений — службы пакетной
обработки, для которых запросы на обращение могут обрабатываться в
течение всего того времени, пока обращение ожидает выполнения.
18
1.2.4 Передача параметров

Большинство систем RMI поддерживает ссылки на объекты в пределах
системы, возможности по передаче параметров при обращениях к методам
обычно не ограничены. Однако существуют определенные тонкости, которые
могут усложнить обращения.
 При обращении к методу с использованием ссылки на объект в
качестве параметра эта ссылка копируется и передается как параметрзначение только тогда, когда она относится к удаленному объекту.
Именно в этом случае происходит передача объекта по ссылке. Однако
если ссылка относится к локальному объекту, то есть к объекту в
адресном пространстве клиента, то объект, на который указывает
ссылка, целиком копируется и в процессе обращения передается
клиенту. Другими словами, объект передается по значению.
 Дополнительный эффект обращения к методам с использованием в
качестве параметра ссылки на объект состоит в возможности
копирования объектов.
19
1.2.4 Передача параметров
Эти две ситуации
показаны на рис. 1.3, на
котором изображены
клиентская программа,
выполняемая на машине А, и
программа-сервер,
выполняемая на машине С.
Клиент обладает ссылкой
на локальный объект 01,
который используется в
качестве параметра при
вызове серверной программы
на машине С. Кроме того, он
обладает ссылкой на
находящийся на машине В
удаленный объект 02, который
также используется в качестве
параметра. При вызове
сервера на машину С
передается копия всего
объекта 01 и копия ссылки на
объект 02.
20
1.2.4 Передача параметров
Модель распределенных обьектов DCE
Распределенные объекты в DCE описываются на IDL и реализуются на C++.
Распределенные объекты имеют вид удаленных объектов, реализация которых
находится на сервере. Сервер отвечает за локальное создание объектов C++ и
обеспечение доступа к их методам с удаленных клиентских машин.
Поддерживаются два типа распределенных объектов.

Динамические распределенные объекты (distributed dynamic objects) — это
объекты, которые создаются сервером локально по требованию клиента. Для
создания такого объекта сервер должен получить запрос от клиента. Каждый
класс, чтобы иметь возможность создавать динамические объекты, должен
содержать процедуру create. После создания динамического объекта управление
им переходит к исполняющей системе DCE.

Именованные распределенные объекты (distributed named objects) не
предназначены для работы с единственным клиентом. Они создаются сервером
для совместного использования несколькими клиентами. Именованные объекты
регистрируются службой каталогов, так что клиент может найти объект и
выполнить привязку к нему. Регистрация означает сохранение уникального
идентификатора объекта, а также информации о том, как соединиться с сервером
объекта.
21
1.2.4 Передача параметров
Модель распределенных обьектов DCE
22
1.2.4 Передача параметров
Обращение к удаленным обьектам в DCE

Клиент, обращаясь к методу, передает серверу идентификатор объекта,
идентификатор интерфейса, содержащего метод, идентификацию самого
метода и параметры.

Сервер поддерживает таблицу объектов. С помощью этой таблицы
сервер, получив идентификатор объекта и идентификатор интерфейса,
идентифицирует объект, к которому обратился клиент. Затем он выбирает
запрошенный метод и передает ему параметры.

Поскольку сервер может поддерживать тысячи объектов, DCE
предоставляет возможность не держать все объекты в памяти, а помещать их
при необходимости во вспомогательное хранилище данных. Когда к серверу
приходит запрос на обращение к объекту, отсутствующему в таблице
объектов, исполняющая система может вызвать специализированную
функцию поиска, которая извлечет объект из хранилища и поместит его в
адресное пространство сервера. Обращение к объекту произойдет после его
помещения в оперативную память.
23
Сохранность во взаимодействиях
Обобщенная организация коммуникационной системы, хосты которой
соединяются через сеть
Сохранная связь
При сохранной связи сообщение, предназначенное для отсылки, хранится в
коммуникационной системе до тех пор, пока его не удастся передать получателю.
Поэтому у отправляющего сообщение приложения нет необходимости после
отправки сообщения продолжать работу. Аналогично, у приложения,
принимающего сообщения, также нет необходимости находиться в рабочем
состоянии во время отправки сообщения.
Нерезидентная связь
При нерезидентной связи сообщение хранится в системе только в течение времени
работы приложений, которые отправляют и принимают это сообщение.
Обычно все коммуникационные службы транспортного уровня поддерживают
только нерезидентную связь. В этом случае коммуникационный сервер
соответствует традиционному маршрутизатору «получил — передал». Если
маршрутизатор не в состоянии переслать сообщение следующему маршрутизатору
или принимающему хосту, сообщение просто теряется.
Синхронная и асинхронная связь
Характерной чертой асинхронной связи (asynchronous communication)
является немедленное после отправки письма продолжение работы
отправителя. Это означает, что письмо сохраняется в локальном буфере
передающего хоста или на ближайшем коммуникационном сервере.
В случае синхронной связи (synchronous communication) отправитель
блокируется до того момента пока его сообщение не будет сохранено в
локальном буфере принимающего хоста или доставлено реальному
получателю.
В случае сохранной асинхронной связи сообщение сохраняется в буфере либо
локального хоста, либо первого коммуникационного сервера. Этот вид связи
обычно используется в системах электронной почты.
В случае сохранной синхронной связи сообщения хранятся только на
принимающем хосте. Отправитель блокируется до момента сохранения
сообщения в буфере получателя.
Синхронная и асинхронная связь
Нерезидентная асинхронная связь характерна для служб дейтаграмм
транспортного уровня, таких как UDP. Когда приложение отправляет сообщение,
оно временно сохраняется в локальном буфере передающего хоста, после чего
отправитель немедленно продолжает работу. Параллельно коммуникационная
система направляет сообщение в точку, из которой, как ожидается, оно сможет
достигнуть места назначения, возможно, с сохранением в локальном буфере. Если
получатель в момент прихода сообщения на принимающий хост неактивен,
передача обрывается.
Нерезидентная синхронная связь существует в различных вариантах. В наиболее
слабой форме, основанной на подтверждениях приема сообщений, отправитель
блокируется до тех пор, пока сообщение не окажется в локальном буфере
принимающего хоста. После получения подтверждения отправитель продолжает
свою работу.
Нерезидентная связь на основе сообщений
Сокеты Беркли
сокет (socket) — это конечная точка коммуникации. В эту точку приложение может
записывать данные, которые следует переслать по базовой сети, и из этой точки оно
может читать приходящие данные. Сокеты образуют абстракцию, лежащую поверх
реальной конечной точки сети, которая работает с локальной операционной
системой по некоторому транспортному протоколу.
При вызове примитива socket вызывающий процесс создает новую конечную
точку для некоторого транспортного протокола.
Примитив bind выполняет привязку локального адреса к только что созданному
сокету.
Примитив listen применяется только для коммуникаций, ориентированных на
соединение.
Вызов примитива accept блокирует вызывающий процесс до прихода запроса на
соединение.
Общая схема
ориентированного
на соединение
взаимодействия с
использованием
сокетов
Интерфейс передачи сообщений
Интерфейс передачи сообщений ( MPI) разрабатывался для параллельных
приложений, но затем был перенесен на нерезидентное взаимодействие. Он
предполагает использование базовых сетей и не предусматривает ничего,
напоминающего коммуникационные серверы . Кроме того, он предусматривает,
что серьезные сбои в системе, такие как аварии процессов или участков сети,
фатальны и не могут быть восстановлены автоматически.
Сохранная связь на основе сообщений
Модель очереди сообщения
Важный момент в системах очередей сообщений состоит в том, что отправитель
обычно в состоянии гарантировать только попадание сообщения рано или
поздно в очередь получателя. Никакие гарантии относительно того, будет ли
сообщение действительно прочитано, невозможны, это полностью определяется
поведением получателя.
Отправитель и получатель могут
выполняться абсолютно независимо
друг от друга. Как только сообщение
поставлено в очередь, оно будет
оставаться в ней до удаления,
независимо от того, активен его
отправитель или его получатель.
Четыре комбинации слабосвязанных взаимодействий с использованием очередей
a) как отправитель, так и получатель в ходе всего процесса передачи
сообщения находятся в активном состоянии.
б) активен только отправитель, в то время как получатель отключен, то
есть находится в состоянии, исключающем возможность доставки
сообщения. Тем не менее отправитель все же в состоянии
отправлять сообщения.
в) комбинация из активного получателя и пассивного отправителя . В
этом случае получатель может прочитать сообщения, которые были
посланы ему ранее, наличия работающих отправителей этих
сообщений при этом совершенно не требуется.
г) система сохраняет и, возможно, передает сообщения, даже при
неработающих отправителе и получателе.
Общая архитектура системы очередей сообщений
Отношение между
адресацией на
уровне очередей и
на сетевом уровне
Обобщенная
организация систем
очередей
сообщений с
маршрутизаторами
Брокеры сообщений
В системах очередей сообщений преобразование производится на специальных
узлах сети массового обслуживания, известных под названием брокеров
сообщений. Брокер сообщений работает как шлюз прикладного уровня в
системе очередей сообщений. Его основная задача — преобразование входящих
сообщений в формат, который понимается целевым приложением. Заметим, что
для системы очередей сообщений брокер сообщений— это просто еще одно
приложение.
Обобщенная организация брокера сообщений в системе очередей сообщений
Связь на основе потоков данных
Поддержка непрерывных сред
Под средой понимается то, что несет информацию. Сюда могут входить среды
передачи и хранения, среда представления, например монитор, и т. д.
Важнейшая характеристика среды — способ представления информации.
Другими словами, как информация кодируется в компьютерной системе.
В непрерывной среде представления временные соотношения между
различными элементами данных лежат в основе корректной интерпретации
смысла данных.
В отличие от непрерывной среды дискретная среда представления,
характеризуется тем, что временные соотношения между элементами данных
не играют фундаментальной роли в правильной интерпретации
данных.
Потоки данных
Для обмена критичной ко времени передачи информацией распределенные системы обычно
предоставляют поддержку потоков данных. Поток данных есть не что иное, как последовательность
элементов данных. Потоки данных применимы как для дискретной, так и для непрерывной среды
представления.
Передача потока данных по сети между двумя
процессами (а)между двумя устройствами(б)
Пример групповой рассылки потока
данных нескольким получателям
Потоки данных и качество обслуживания
Временные зависимости и другие нефункциональные требования обычно
выражаются в виде требований к качеству обслуживания (QoS). Требования
QoS для непрерывных потоков данных в основном характеризуются
временными диаграммами, объемом и надежностью.
Специфика QoS
Требования QoS могут быть выражены по-разному. Один из подходов —
предоставить точную спецификацию передачи, содержащую требования по
пропускной способности, скорости передачи, задержке и т. п.
Спецификация
передачи
В этой модели характеристики потока формулируются в понятиях алгоритма
корзины элементарных пакетов, который описывает, каким образом поток
формирует сетевой трафик.
Принцип работы этого алгоритма иллюстрирует
Принцип работы алгоритма корзины элементов пакетов
Создание потока
После того как поток данных описан, РС должна захватить ресурсы для создания потока,
удовлетворяющего требованиям QoS. В контексте управления потоками, ресурсами обычно
являются пропускная способность, буферы и вычислительная мощность. Выделение
пропускной способности производится для того, чтобы гарантировать соблюдение графика
передачи элементов данных.
Выделение буферов в маршрутизаторах и операционных системах позволяет сохранять
элементы данных для дальнейшей обработки.
И наконец, необходимо, чтобы обработка элементов данных выполнялась за время,
отводимое на это соответствующими задачам — планировщикам, кодерам и декодерам,
фильтрам и др.
Одна из тех проблем, которые следует решить, состоит в том, что параметры,
характеризующие требования QoS к потоку данных, не соотносятся напрямую
с параметрами соответствующих ресурсов.
К сожалению, в настоящее время не существует единственно лучшей модели для:
1. выбора параметров QoS,
2. обобщенного описания ресурсов в любой коммуникационной системе
3. преобразования параметров QoS в значения используемых ресурсов.
Протокол резервирования ресурсов
Протокол резервирования ресурсов (RSVP) — это управляющий протокол транспортного
уровня для резервирования ресурсов сетевых маршрутизаторов.
Основы организации
процесса RSVP для
резервирования
ресурсов в
распределенных
системах
Синхронизация потоков данных
В мультимедийных системах важное значение имеет взаимная синхронизация
разных потоков данных, возможно, собранных в комплексный поток.
Синхронизация потоков данных подразумевает поддержание временных
соотношений между ними. Существует два типа синхронизации.
Простейшая форма синхронизации имеет место между дискретными и
непрерывными потоками данных.
Более сложный тип синхронизации наблюдается между непрерывными
потоками данных.
Синхронизация происходит на уровне элементов данных, из которых состоит
поток. Другими словами, мы можем синхронизировать два потока только
относительно элементов данных. Выбор элементов данных очень сильно
зависит от уровня абстракции представления потока данных.
Механизмы синхронизации
Рассмотрим как на самом деле обеспечивается синхронизация.
Следует рассмотреть два момента: во-первых, базовые механизмы синхронизации
двух потоков данных и, во-вторых, распределение этих механизмов в сетевой среде.
Механизмы синхронизации могут рассматриваться с позиций разных уровней
абстракции. С точки зрения самого нижнего, синхронизация полностью определяется
работой с элементами данных простых потоков. Этот принцип иллюстрирует
Принцип явной синхронизации на уровне элементов данных
В сущности, здесь показан процесс, который осуществляет операции чтения и
записи в нескольких простых потоках данных.
Механизмы синхронизации
Оборотная сторона подобного подхода состоит в том, что приложение может
полностью отвечать за синхронизацию только в том случае, если оно имеет доступ к
механизмам низкого уровня. Лучше будет предоставить приложению интерфейс, который
упростил бы ему управление потоками и устройствами.
Принцип синхронизации, поддерживаемой высокоуровневыми интерфейсами
Итоги
Наличие мощных и гибких механизмов взаимодействия между процессами
является важным для всякой распределенной системы. В традиционных сетевых
приложениях связь часто базируется на низкоуровневых примитивах передачи
сообщений, предоставляемых транспортным уровнем. Важной особенностью
систем промежуточного уровня является предоставляемая ими высокая степень
абстракции, благодаря которой описание взаимодействия между процессами на
промежуточном уровне значительно проще, чем если бы мы ограничились
только интерфейсами транспортного уровня.
RMI предоставляют механизмы синхронной связи, при которой клиент
блокируется до получения ответа от сервера. Несмотря на вариации
существующих механизмов, в которых жесткая синхронная модель смягчена,
нередко более удобными оказываются универсальные высокоуровневые
модели, ориентированные на передачу сообщений.
Итоги
В моделях передачи сообщений неважно, является ли связь сохранной, так
же как неважно и то, является ли она синхронной. Смысл сохранной связи состоит в том,
что посылаемое сообщение хранится в коммуникационной системе до тех пор, пока не
будет доставлено по назначению. Другими словами, ни отправитель, ни получатель при
передаче сообщения не обязаны быть активными. В случае нерезидентной связи
механизмы хранения не предусмотрены, а значит, получатель должен быть готов принять
сообщение, когда бы оно ни было послано.
При асинхронной связи отправитель может продолжать работу сразу после
установки сообщения в очередь на отправку, возможно, еще до того, как оно будет
отправлено. При синхронной связи отправитель блокируется как минимум до момента
получения сообщения.
Итоги
Модели обмена сообщениями промежуточного уровня обычно предоставляют сохранную
асинхронную связь и используются там, где применение механизмов RMI не оправдано. В
первую очередь это интеграция наборов баз данных (сильно распределенных) в крупных
информационных системах. Другие области их применения включают в себя электронную
почту и рабочие потоки. Абсолютно иную связь предлагают потоки данных, проблема
которых состоит в том, что любые два последовательных сообщения взаимосвязаны по
времени. В непрерывных потоках данных максимальная задержка доставки своя для каждого
сообщения. Кроме того, необходимо, чтобы сообщения обладали определенной
минимальной задержкой доставки. Типичными примерами непрерывных потоков данных
являются аудио- и видеопотоки. Часто бывает сложно описать, какими должны быть
временные взаимосвязи или чего мы ожидаем от базовой подсистемы связи (в терминах
качества обслуживания).