Слайд 1Распределенные системы
Коммуникации
Слайд 2СВЯЗЬ в РАСПРЕДЕЛЕННЫХ СИСТЕМАХ
Сетевые протоколы
Слайд 3Роль связи в распределенных системах
Связь между процессами исполняемыми на взаимодействующих
друг с другом узлах РИС – определяет суть распределенных систем.
Обмен
информацией между узлами выполняется с использованием протоколов сетевой модели используемой в распределенной системе.
Сетевая модель относится к инфраструктуре в которой функционирует РС.
Слайд 4Сетевая модель OSI/ISO
Уровни, интерфейсы и протоколы модели OSI
Протоколы бывают:
-
с установлением соединения;
- без установления соединения.
Слайд 5Структура сетевого сообщения
Структура сетевого сообщения
Слайд 6 Сеансовая и транспортная подсистемы
Слайд 7Соответствие популярных стеков протоколов модели OSI
Слайд 8Сетевая модель TCP/IP
В настоящее время стек протоколов TCP/IP является основной
сетевой моделью, поддерживаемой всеми операционными системами узлов распределенных систем.
Слайд 9Протоколы промежуточного уровня
По сравнению с моделью OSI сеансовый уровень и
уровень представления заменены одним промежуточным уровнем, который содержит не зависящие
от приложений протоколы, эти протоколы нельзя поместить на более низкие уровни. Транспортные службы также могут быть представлены в виде служб промежуточного уровня.
К промежуточному уровню относятся приложения, логически помещаемые на прикладной уровень, но содержащие множество протоколов общего назначения.
Примеры протоколов поддерживаемых
ПО промежуточного уровня:
- протокол DNS;
протоколы аутентификации;
- протоколы распределенного подтверждения;
протоколы распределенной блокировки;
- протоколы удаленного вызова процедур; удаленного вызова методов; удаленного обращения к объектам;
- протоколы обмена сообщениями.
Слайд 10Коммуникаций на уровне ПО промежуточного слоя. Критерии коммуникаций
Для понимания
альтернатив организации связи на уровне ПО промежуточного слоя необходимо определить
основные критерии таких коммуникаций.
Такими критериями, коммуникаций являются:
Время хранения сообщения.
Синхронность выполнения, различают типы .
Особенность природы данных.
Слайд 11Сохранная и нерезидентная связь
Время хранения сообщения, по этому критерию различают
типы:
Сохранная (persistent) связь (коммуникации) - сообщение, предназначенное для отсылки, хранится
в коммуникационной системе до тех пор, пока его не удастся передать получателю;
Нерезидентная (transient - краткосрочная) связь (коммуникации) - сообщение хранится в системе только в течение времени работы приложений, которые отправляют и принимают это сообщение;
Слайд 12Синхронная и асинхронная связь
Синхронность выполнения, различают типы :
Асинхронная связь -
является немедленное после отправки письма продолжение работы отправителя. Это означает,
что письмо сохраняется в локальном буфере передающего хоста или на ближайшем коммуникационном сервере;
Синхронная связь - отправитель блокируется до того момента пока его сообщение не будет сохранено в локальном буфере принимающего хоста или доставлено реальному получателю. Наиболее жесткая форма синхронного взаимодействия предполагает, что отправитель остается блокированным и на время обработки его сообщения получателем.;
Слайд 13Дискретные и потоковые данные
Особенность данных:
Отдельные блоки данных (дискретные данные);
Потоки данных
(непрерывные последовательности данных).
Слайд 14Обобщенная организация коммуникационной системы,
хосты которой соединяются через сеть
Приложения всегда выполняются
на хостах, а каждый хост предоставляет интерфейс с коммуникационной системой,
через который сообщения могут передаваться.
Хосты соединены сетью коммуникационных серверов, которые отвечают за передачу (или маршрутизацию) сообщения между хостами.
Без потери общности можно предположить, что каждый из хостов связан только с одним коммуникационным сервером.
Слайд 15Пример: электронная почта
Для понимания различных альтернатив в коммуникациях промежуточного уровня
необходимо рассмотреть модель взаимодействия клиент-сервер, на примере электронной почты.
Компоненты службы
эл. Почты:
МТА – транспортный агент, сервер доставки эл.почты
(протокол SMTP)
ДА – агент доставки эл. почты (утилита mail) доставляет сообщение в почтовый ящик пользователя;
UA – пользовательский агент, доставляет сообщение на машину пользователя (протокол POP3/IMAP4);
Клиент SMTP – клиентское ПО отправки сообщений эл. почты (SMTP);
Слайд 16Типы коммуникаций используемые в службе электронной почты
Сообщение отправляемое клиентом на
сервер, сохраняется на сервере для дальнейшей доставки с помощью средств
ПО промежуточного слоя, т.е. имеет место сохранность коммуникации.
Асинхронность коммуникации имеет место, когда сервер начинает доставку сразу же после приема сообщения, а клиент, может продолжить свою работу после приема сообщения сервером.
Синхронность предполагает ожидание клиентом завершения выполнения сервером обработки запроса.
Система электронной почты — это типичный пример сохранной связи (persistent
communication).
Слайд 17Виды связи в распределенных системах (1). сохранная асинхронная связь
В
случае сохранной асинхронной связи сообщение сохраняется в буфере либо локального
хоста, либо первого коммуникационного сервера.
Этот вид связи обычно используется в системах электронной почты.
Почтовая служба Pony Express, легендарная американская почтовая служба существовала в период с 1860 по 1861 год.
Слайд 18(2). сохранная синхронная связь
В случае сохранной синхронной связи сообщения
хранятся только на принимающем хосте.
Отправитель блокируется до момента сохранения
сообщения в буфере получателя. Отметим, что приложение, принявшее сообщение, не обязано сохранять его на своем локальном хосте.
«Усеченный» вариант сохранной синхронной связи состоит в том, что отправитель блокируется до момента сохранения сообщения на коммуникационном сервере, соединенном с принимающим хостом.
Слайд 19(3). нерезидентная асинхронная связь.
Нерезидентная асинхронная связь характерна для служб дейтаграмм
транспортного уровня, таких как UDP.
Когда приложение отправляет сообщение, оно
временно сохраняется в локальном буфере передающего хоста, после чего отправитель немедленно продолжает работу.
Параллельно коммуникационная система направляет сообщение в точку, из которой, как ожидается, оно сможет достигнуть места назначения, возможно, с сохранением в локальном буфере.
Если получатель в момент прихода сообщения на принимающий хост этого получателя неактивен, передача обрывается.
Другой пример нерезидентной асинхронной связи — асинхронный вызов RPC.
При асинхронных вызовах
RFC клиент синхронизируется с сервером, ожидая, пока его запрос будет принят на дальнейшую обработку.
Слайд 20(4). нерезидентная синхронная связь с синхронизацией по приему
Нерезидентная синхронная
связь существует в различных вариантах.
В наиболее слабой форме, основанной
на подтверждениях приема сообщений, отправитель блокируется до тех пор, пока сообщение не окажется в локальном буфере принимающего хоста.
После получения подтверждения отправитель продолжает свою работу.
Слайд 21(5). нерезидентная синхронная связь с синхронизацией по доставке
В ориентированной
на доставку нерезидентной синхронной связи отправитель блокируется до тех пор,
пока сообщение не будет доставлено получателю для дальнейшей обработки.
При синхронных вызовах
RРC клиент синхронируется с сервером, ожидая, пока его запрос будет обработан сервером.
Слайд 22(6). нерезидентная синхронная связь с синхронизацией по ответу
Наиболее жесткая
форма — ориентированная на ответ нерезидентная синхронная связь — предполагает
блокировку отправителя до получения ответного сообщения с другой стороны, как в поведении запрос-ответ при взаимодействии клиент-сервер.
Эта схема характерна также для механизмов RPC и RMI.
Слайд 23Применение различных типов коммуникаций в РС
Ассинхронная связь – является более
быстрой, более гибкой, но более сложной в программной реализации, т.к.
ответ может поступить в непредсказуемый момент времени.
Используется в системах основанных на событиях (Event-based systems).
Полностью синхронный вариант коммуникаций может сильно замедлить процесс обработки, но программная реализация его более проста и понятна.
При использовании мультипотоковых программных реализаций ПО промежуточного слоя блокировка одного из процессов, не представляет собой большой проблемы, т. к. отдельный поток может отслеживать (ожидать) появление ответных сообщений.
Слайд 24Дискретные и потоковые коммуникации
Дискретными – называются коммуникации в рамках которых
передаются отдельные блоки данных, порядок передачи которых может быть изменен.
А задержка и стабильность скорости передачи не имеют значения для передаваемых блоков данных.
Потоковыми – называются данные передаваемые в одном направлении (one-way communication); сессия содержит множество сообщений поступающих от отправителя в определенном порядке, который определяется либо порядком передачи, либо порядком передачи по времени, либо еще чем либо.
Слайд 25Методы организации обмена данными в распределенных системах
Методы коммуникаций ПО промежуточного
слоя
Слайд 26Методы коммуникаций ПО промежуточного слоя
Удаленный вызов процедур (Remote Procedure Call)
Коммуникации
ориентированные на работу с сообщениями (Message-Oriented Communication)
Коммуникации ориентированные на работу
с потоками (Stream-Oriented Communication)
Групповые коммуникации (Multicast Communication)
Слайд 28Мотивация использования RPC
Использовать низкоуровневый обмен сообщениями на основе функций встроенных
в язык программирования (примитивов) send и receive. primitives.
Стремление к обеспечению
прозрачности на уровне доступа (access transparency).
Сокрытие различий в представлениях данных на машинах, в понимании процессов обмена сообщениями и т.п. Другими словами - сделать RPC прозрачным: вызывающей процедуре не требуется знать, что вызываемая процедура находится на другой машине, и наоборот.
Упрощение программирования процесса обмена информацией за счет использования методов подобных тем, которые применяются при обмене через разделяемую память при локальном вызове процедур.
Впервые идея RPC была предложена Birrell and Nelson (1984)
Слайд 29Модель Remote Procedure Call (RPC)
Использование высокоуровневых интерфейсов сетевых коммуникаций, предоставляемых
ОС.
Основан на модели вызова локальных процедур в рамках одного процесса.
Запрос
клиента: оформляется как вызов процедуры выполнения функции на сервере.
Ответ сервера: оформляется как возвращение результата выполнения вызванной функции.
Слайд 30Традиционный (локальный) вызов процедуры. Инициация
Инициируется вызовом процессом функции или процедуры.
Вызывающий
процесс приостанавливается (suspended ) до тех пор пока выполнение вызываемой
процедуры не будет завершено.
Аргументы и адрес возврата помещаются в стек процесса.
Локальные переменные для использования в вызываемой процедуре также помещаются в стек.
Слайд 31Передача параметров при локальном вызове процедуры
Передача параметров при локальном вызове
процедуры:
Стек до вызова функции read (а).
Стек во время
работы вызванной процедуры (б)
Указатель стека
Указатель стека
count = read(fd, buf, bytes);
Пусть это, например, будет системный вызов
count=read (fd,buf,nbytes);
где fd - целое число,
buf - массив символов,
nbytes - целое число.
Слайд 32Функционирование RPC
Приложения RPC похожи на другие структурированные приложения:
у них
есть основная программа, которая для выполнения специфических задач вызывает процедуры
или библиотеки процедур.
Отличие приложений RPC от обычных программ в том, что некоторые библиотеки процедур в приложениях RPC выполняются на удаленных компьютерах, а некоторые — на локальном.
Для приложения RPC все процедуры кажутся локальными.
Функционирует приложение RPC следующим образом. В процессе своей работы оно вызывает как локальные процедуры, так и процедуры, отсутствующие на локальной машине.
Для обработки последнего случая приложение связывается с локальной DLL, которая содержит интерфейсные процедуры (stub procedures) для всех удаленных процедур. В простой программе интерфейсные процедуры статически связываются с приложением, но в компоненте большего размера они включаются в отдельные DLL.
В DCOM обычно применяется последний метод. Интерфейсная процедура имеет то же имя и тот же интерфейс, что и удаленная процедура, но вместо выполнения соответствующей операции она просто преобразует переданные ей параметры для передачи по сети — такой процесс называется маршалингом
(marshaling).
Маршалинг заключается в упорядочении параметров и их упаковке в определенном формате.
Далее интерфейсная процедура вызывает процедуры библиотеки RPC периода выполнения, и они находят компьютер, на котором расположены удаленные процедуры, определяют используемые этим компьютером механизмы транспорта и посылают запрос при помощи локального программного обеспечения сетевого транспорта. Когда удаленный сервер получает запрос RPC, он выполняет обратное преобразование параметров
Слайд 33Локальный вызов процедур. Выполнение
Управление передается вызываемой функции (процедуре)
Вызванная функция выполняется
и по завершении работы возвращает результаты либо через параметры (стек),
либо сохраняет их в регистрах CPU.
Выполняется извлечение данных из стека.
Процесс вызывавший процедуру продолжает свою работу.
Слайд 34Особенности Remote Procedure Calls
Основные операции RPC выполняются параллельно с выполнением
процесса вызвавшем RPC процессом.
Процесс вызвавший RPC выполняет удаленный вызов при
этом его работа приостанавливается до завершения выполнения вызываемой функции и возвращения результатов.
Параметры передаются на машину, на которой процедура будет исполняться.
Когда выполнене вызываемой процедуры будет завершено, результаты передаются назад на машину источник вызова, после чего клиентский процесс продолжит свою работу.
Слайд 35RPC и модель Клиент-Сервер
RPC лежит в основе большинства систем клиент-сервер.
Клиенты
формулируют запросы к серверам в виде вызовов процедур.
Прозрачность доступа обеспечивает
реализация механизма RPC
Существующие реализации RPC ?
Слайд 36Реализация прозрачности: Использование программных заглушке (Stubs)
Программные заглушки создаются для каждого
вызова RPC (по одной для каждого RPC)
Передача данных серверной
процедуре. Для каждого RPC управление потоком передаваемых данных выполняется с помощью:
Приложение клиент управляет обменом данных с клиентской заглушкой (client-side stub)
Клиентская заглушка (client stub ) управляет передачей параметров серверной заглушке (server stub).
Серверная заглушка (server stub) обеспечивает передачу данных серверной процедуре (server procedure).
Возврат данных от серверной процедуры. В этом случае управление распределяется следующим образом:
Серверная процедура передает результаты выполнения серверной заглушке.
Серверная заглушка отсылает результаты по сети клиентской заглушке.
Клиентская заглушка передает результаты клиентскому приложению.
Слайд 37Заглушки клиента и сервера
- Cпециальная версия функции read, называемая клиентской
заглушкой {client stub}
- Серверная заглушка эквивалентна клиентской, но
работает на стороне сервера.
Слайд 38Работа клиентской заглушки
Когда приложение выполняет вызов RPC клиентская заглушка выполняет:
Создает
сообщение содержащее параметры и обращается к локальной ОС с вызовом
функции (send) для отправки сообщения.
Процесс подготовки параметров в виде пакета передаваемого по сети называется маршалингом параметров (parameter marshalling).
Выполняет вызов процедуры receive( ) для ожидания ответа (блокирующая функция receive).
Слайд 39Действия выполняемые OS (OS Layer Actions)
Клиентская ОС отправляет сообщение к
удаленной машине по сети.
Удаленная ОС передает принятое сообщение серверной заглушке.
Слайд 40Действия выполняемые серверной заглушкой
Распаковка параметров, выполнение вызова серверной процедуры.
После выполнения
процедуры сервером, полученный результат поступает серверной заглушке. Серверная заглушка пакует
результат в ответное сообщение.
Выполняет вызов ОС для отправки сообщения на клиентскую машину.
Слайд 41Действия выполняемые серверной и клиентской ОС
Серверная ОС отсылает сообщение –
ответ клиенту.
Клиентская ОС принимает сообщение – ответ и передает его
клиентской заглушке.
Слайд 42Действия выполняемые клиентской заглушкой при получении ответа
Клиентская заглушка распаковывает ответное
сообщение и передает результат клиентскому приложению, используя один из нормальных
механизм передачи результатов от функций:
Либо напрямую, в виде значений,
Либо через параметры вызова функции.
Слайд 43Работа RPC
При удаленном вызове процедур происходят следующие действия:
Процедура клиента обычным
образом вызывает клиентскую заглушку.
Клиентская заглушка создает сообщение и вызывает локальную
операцион
ную систему.
Операционная система клиента пересылает сообщение удаленной операцион
ной системе.
Удаленная операционная система передает сообщение серверной заглушке.
Серверная заглушка извлекает из сообщения параметры и вызывает сервер.
Сервер выполняет вызов и возвращает результаты заглушке.
Серверная заглушка запаковывает результаты в сообщение и вызывает свою
локальную операционную систему.
Операционная система сервера пересылает сообщение операционной системе
клиента.
Операционная система клиента принимает сообщение и передает его клиентской заглушке.
Заглушка извлекает результаты из сообщения и передает их клиенту.
Схема обмена между сервером и клиентом RPC
Слайд 44Передача значений параметров
Figure 4-7. The steps involved in a doing
a remote computation through RPC.
Слайд 45Проблемы организации взаимодействия RPC (1). Передача параметров
Основная функция клиентской заглушки
является прием параметров и их передача серверной стороне. Следовательно необходимо
согласовать один из возможных способов передачи – приема параметров. Например возможны варианты передачи параметров:
- по значению,
- по ссылке,
- путем копирования/восстановления.
Согласование форматов передаваемых сообщений и видов представления простых типов данных;
Слайд 46Проблемы передачи параметров
Выбор способа передачи параметров - по значению (call-by-value)
или по ссылке (call-by-reference).
Передача параметров по значению (Call-by-value): выполняется в
рамках того же процесса в котором выполняется вызов RPC. Значения параметров помещаются в стек процесса и действуют как локальные переменные.
Передача параметров по ссылке (Call-by-reference): выполняется в рамках того же процесса в котором выполняется вызов RPC. Указатель на структуру параметров помещается в стек процесса.
Выбор представления данных.
Выбор сетевого протокола для сетевого взаимодействия между клиентом и сервером.
Слайд 47Передача параметров по значению
В этом случае значения параметров вызова удаленной
процедуры могут быть помещены непосредственно в сообщение – запрос и
доставлены напрямую вызываемой процедуре, если …
В обеих машинах используются одни и теже способы внутреннего представления данных (кодировка символов, представления чисел и т.п.)
в машинах используются одинаковые способы адресации байт в машинном слове (остроконечное - little endian или тупоконечное big endian).
Слайд 48Передача параметров по ссылке
Предполагает передачу ссылки на обыкновенный массив:
Передается ссылка
на массив с помощью указателя.
Функция использует указатель для прямого обращения
к массиву значений параметров, расположенному в адресном пространстве вызываемой функции.
Указатель = машинный адрес; есть опасность, что для удаленной машины будет указывать на несоответствующий сегмент памяти.
Решение: массив значений копируется в сообщение-запрос; затем сохраняется в адресном пространстве серверной заглушки. Серверный процесс использует указатель для доступа к сохраненному массиву параметров.
Слайд 49Проблемы RPC:
Согласование интерфейсов
4. Согласование интерфейсов обращения к заглушкам клиента
и сервера;
Для упрощения работы интерфейсы часто описываются с использованием
языка определения интерфейсов (Interface Definition Language, IDL).
Слайд 50Проблемы RPC.
Генерация кодов заглушек
5. Обеспечение генерации кодов заглушек клиента и
сервера;
Интерфейс, определенный на чем-то вроде IDL, компилируется затем в заглушки
клиента и сервера, а также в соответствующие интерфейсы времени компиляции и времени выполнения.
Слайд 51Проблемы RPC
Решение проблемы сетевой идентификации серверов и механизмы их поиска
клиентами;
Связывание (привязка клиента к серверу)
Как показано на рисунке, привязка выполняется
в несколько этапов.
Регистрация конечной точки.
Регистрация службы.
Поиск сервера службы каталогов.
Опрос конечной точки.
Выполнение вызова RPC.
Слайд 52Другие трудности
Клиент и сервер должны согласовать:
Формат сообщений, которыми они будут
обмениваться (Message format).
Формат сложных структур данных (Format of complex data
structures).
Транспортный протокол (TCP или UDP).
Слайд 53Проблемы RPC.
Согласование сетевых протоколов
Например, стороны могут решить использовать транспортный
протокол с соединениями, такой как TCP/IP.
Альтернативой ему будет ненадежная
служба дейтаграмм, в этом случае клиент и сервер должны включить реализацию схемы контроля ошибок в RPC.
На практике возможны различные варианты.
Слайд 54Надежный или не надежный RPC
Если RPC построен на использовании надежного
транспортного протокола (например ТСР), то будет обеспечиваться более надежная работа
приложений.
С другой стороны, при использовании более быстрого протокола, будет обеспечиваться более быстрая работа клиент-серверных систем.
Слайд 55Асинхронный RPC
Позволяет клиенту продолжать исполнение после выполнения вызова сервера, до
завершения обработки запроса сервером и получения результата.
Может использоваться для выполнения
действий не требующих ответа, например, обращения к принтерам, удаление файлов и т.п.
Также может использоваться в случаях, когда клиент желает выполнять некоторые операции не связанные с ответом на RPC. В этом случае увеличивается суммарная производительность машины клиента.
При этом остается проблема ненадежного асинхронного RPC.
Слайд 56Synchronous RPC
Взаимодействие между клиентом и сервером при традиционном (синхронном) RPC.
Слайд 57Asynchronous RPC
Взаимодействие между клиентом и сервером при использовании асинхронного RPC.
Слайд 58Asynchronous RPC
Случай когда клиент и сервер взоимодействуют друг с другом
через асинхронные RPC.
Слайд 59Примеры использования RPC
Распределенные файловые системы: обеспечивают доступ к файлам системы,
в том числе и глобальный.
Служба каталогов: отслеживает и управляет системными
ресурсами (машины, принтеры, серверы и т.п.).
Служба безопасности: ограничение доступа к ресурсам.
Распределенная служба времени: пытается синхронизировать все часы в системе.
Слайд 60Примеры реализаций RPC
Sun ONC RPC
DCE RPC
XML RPC
JSON RPC
Слайд 61Наиболее популярные реализации RPC
Sun RPC известный под названием Open Network
Computing (ONC) RPC – широко применяемый стандарт RPC , особенно
в ОС UNIX, Linux и других Unix-подобных системах (Oracle Solaris, FreeBSD, OpenBSD, MacOS X и др.).
DCE RPC: Distributed Computing Environment
Разработана фондом открытого ПО Open Software Foundation (OSF) (не следует путать с Open Source ПО).
Адаптирован как стандарт фирмой Microsoft
Реализован в качестве надежного ПО промежуточного слоя во многих современных ОС.
Обеспечивает работу между операционными системами и пользовательскими приложениями.
Слайд 62Remote Procedure Call (RPC) как стандарт сетевого программирования
RPC — стандарт
сетевого программирования, разработанный в начале 80-х.
Организация Open Software Foundation (теперь
— The Open Group) сделала RPC частью стандарта OSF DCE (Distributed Computing Environment).
Несмотря на наличие второго стандарта RPC, SunRPC, реализация RPC от Microsoft совместима со стандартом OSF DCE.
RPC, опираясь на другие сетевые API (именованные каналы или Winsock), предоставляет альтернативную модель программирования, в какой-то мере скрывающую детали сетевого программирования от разработчика приложений.
Слайд 63Реализация RPC в ОС Windows 2000/XP/2003
Приложение на основе RPC связано
с библиотекой RPC периода выполнения (\Windows\System32\Rpcrt4.dll). Последняя предоставляет для интерфейсных
RPC-функций приложений функции маршалинга, а также функции для приема и передачи упакованных данных. Библиотека RPC периода выполнения включает процедуры поддержки RPC-взаимодействия через сеть и разновидность RPC под названием локальный RPC.
Локальный RPC позволяет двум процессам взаимодействовать в одной системе, при этом библиотека RPC в качестве сетевого API использует LPC в режиме ядра.
Когда RPC-взаимодействие осуществляется между удаленными системами, библиотека RPC использует API-функции Winsock, именованного канала или Message Queuing.
Слайд 64Проблемы RPC: Связывание
Связывание: присвоение значений некоторым атрибутам службы RPC (например,
назначение адресов идентификаторам). В разных стандартах используются разные схемы назначения
атрибутов.
Sun RPC (ONC) выполняет имеет исполняемую службу связывания, работающую на определенном порту на каждом компьютере (the port mapper).
Клиенты находят нужный им сервис с помощью этой службы порт маппера.
В DCE на машинах серверах работает демон хранящий таблицу пар . Также сервер должен зарегистрировать свой сетевой адрес в службе каталогов, работающем в сети.
Слайд 65RPC Выводы
Основан на использовании простой модели вызова функций.
Существующие реализации могут
быть легко адаптированы для работы в рамках распределенных систем.
Обеспечивает высокую
степень прозрачности доступа к службам РС.
Слайд 66Remote Method Invocation (RMI)
Основан на идеях используемых в RPC. Обеспечивает
Java процессу, исполняемому на одной виртуальной Java машине вызывать процесс,
работающий на другой виртуальной Java машине.
Поддерживает создание распределенных Java систем.
Слайд 67Коммуникации ориентированные на передачу сообщений
(Message Oriented Communication)
Слайд 68Message Oriented Communication
Несмотря на то, что RPC и RMI поддерживают
прозрачность доступа, однако не всегда это делается походящим способом.
Коммуникации ориентированные
на обмен сообщениями обладают большей гибкостью.
Эти коммуникации основываются на уровне транспортных протоколов – транспортный уровень OSI.
Стандартизованными интерфейсами к транспортному уровню OSI являются Сокеты :
(Berkeley UNIX);
XTI (X/Open Transport Interface), ранее известные как TLI (AT&T model).
Слайд 69Сокеты
Связь между конечными точками используется приложениями для записи/чтения в/из сети.
Механизм
сокетов предоставляет набор базовых примитивов (функций) для выполнения операций по
передаче и приему данных
Сокеты являются абстракцией реальных коммуникаций с конечными точками обслуживания средствами локальной ОС.
Адрес сокета: Адрес IP + номер порта
Слайд 71Использование сокетов сервером
(How a Server Uses Sockets)
Internetworking with TCP/IP, Douglas
E. Comer & David L. Stevens, Prentice Hall, 1996
Системный вызов:
Socket
Bind
Listen
Accept
Read
Write
Close
Что
означает:
Создать дескриптор сокета.
Привязать локальный IP адрес/порт к сокету.
Перейти в пассивный режим, создать очередь запросов.
Получить следующее сообщение
Читать данные поступающие из сети
Писать данные в сеть.
Разорвать соединение
Repeat accept/close &
read/write cycles
Слайд 72Использование сокетов клиентом
How a Client Uses Sockets
Internetworking with TCP/IP, Douglas
E. Comer & David L. Stevens, Prentice Hall, 1996
Системный вызов:
Socket
Connect
Write
Read
Close
Что означает:
Создать дескриптор сокета.
Подключиться к удаленному серверу
Писать данные в сеть.
Читать данные поступающие из сети
Разорвать соединение
Repeat read/write
cycle as needed
Слайд 73Коммуникации на основе сокетов
Используя сокеты, клиенты и серверы могут устанавливать
между собой связь в рамках сессии ориентированной на соединение (connection-oriented
communication session).
На серверах используются первые четыре функции (socket, bind, listen, accept), в то время как на клиентах используются примитивы (функции) – socket и connect.
Затем на клиенте и сервере поочередно выполняются операции записи-чтения (client/write, server/read, server/write, client/read) а вслучае закрытия соединения операция close, закрывающая соединение.
Слайд 74Общая схема взаимодействия клиента и сервера с использованием сокетов. Сервер.
Общая
схема взаимодействия клиента и сервера с использованием сокетов для коммуникаций,
ориентированных на соединение:
Сервер:
Примитив bind выполняет привязку локального адреса к только что созданному сокету. Например, сервер должен связать IP-адрес своей машины с номером порта (возможно, общеизвестным) сокета. Привязка сообщает операционной системе, что сервер намерен получать сообщения только на указанные адрес и порт.
Примитив listen применяется только для коммуникаций, ориентированных на соединение. Это неблокирующий вызов, требующий от локальной операционной системы зарезервировать буфер для определенного максимального количества соединений, которое вызывающий процесс намерен поддерживать.
Вызов примитива accept блокирует вызывающий процесс до прихода запроса на соединение. Когда этот запрос придет, локальная операционная система создаст новый сокет с теми же свойствами, что и у базового, и возвратит его вызывающему процессу.
Слайд 75Общая схема взаимодействия клиента и сервера с использованием сокетов. Клиент.
На
стороне клиента все начинается с создания сокета при помощи примитива
socket, однако в явной привязке сокета к локальному адресу нет необходимости, поскольку операционная система может динамически выделить порт при установлении соединения.
Примитив connect требует, чтобы вызывающий процесс указал адрес транспортного уровня, на который будет отправлен запрос на соединение.
Клиент блокируется до тех пор, пока соединение не будет установлено. После установления соединения
стороны начинают обмениваться информацией при помощи примитивов write и read, предназначенных для посылки и приема данных соответственно.
Наконец, закрытие соединения при использовании сокетов симметрично и может быть осуществлено как клиентом, так и сервером путем вызова примитива close.
Слайд 76Message-Passing Interface (MPI)
Интерфейс передачи (обмена) сообщений
Слайд 77Интерфейс пересылки сообщений
(Message-Passing Interface - MPI)
Сокеты предоставляют низкоуровневый интерфейс доступа
к глобальным (TCP/IP-based) сетям.
Распределенные системы, работающие на высокоскоростных сетях в
высокопроизводительных кластерных системах требуют более эффективных протоколов обмена сообщениями, обеспечивающих эффективные варианты буферизации и синхронизации.
Часто высокопроизводительные мультикомпьютерные вычислительные системы имеют свои собственные коммуникационные библиотеки.
Необходимость в платформе обмена сообщениями независящей от аппаратной платформы привела к необходимости создания стандарта обмена сообщениями – МРI (Message-Passing Interface ).
Слайд 78MPI (Message-Passing Interface )
MPI - это библиотека спецификаций обмена сообщениями,
предложенная в качестве стандарта (is a library specification for message-passing,
proposed as a standard by) комитетом производителей, реализаторов и пользователей.
MPI разработан для обеспечения обмена сообщениями между узлами вычислительного кластера на основе асинхронной сохранной (persistent) связи сообщений при выполнении параллельных вычислений. Но поддерживаются и синхронные взаимодействия.
MPI используется во многих системных окружениях, включая как вычислительные кластеры, так и гетерогенные сети.
MPI является платформо-независимым решением.
MPICH2 - это популярная реализация стандарта MPI .
Слайд 79Коммуникации в MPI
MPI предполагает использование базовых сетей и не предусматривает
ничего, напоминающего коммуникационные серверы. Кроме того, он предусматривает, что серьезные
сбои в системе, такие как аварии процессов или участков сети, фатальны и не могут быть восстановлены автоматически.
Коммуникации предполагаются между группой процессов известных друг другу.
Для группу прцессов назначается свой уникальный идентификатор - groupID . Для каждого процесса включенного в группу назначается свой идентификатор процесса – processID.
Пара (groupID, processID) выполняют роль адреса процесса при коммуникациях на основе MPI.
Слайд 80Некоторые из наиболее используемых примитивов MPI
Слайд 81Операторы (примитивы) MPI передачи сообщений. Асинхронная связь.
Оператор MPI_bsend: обеспечивает асинхронную
сохранную связь между процессами.
После выполнения этой операции, передающий процесс (sender)
продолжает выполнение кода, одновременно с копирование сообщения в локальный буфер для последующей доставки процессу получателю (bsend = buffer send).
Сообщение будет скопировано в буфер на принимающей машине и позднее будет получено процессом в ответ на выдачу оператора (примитива) receive.
Слайд 82Операторы (примитивы) MPI передачи сообщений. Синхронная связь
MPI_send: блокирует передачу до
тех пор пока сообщение не будет скопировано в локальный или
удаленный буфер. Семантика зависит от реализации.
MPI_ssend: передающий процесс блокируется до тех пор пока запрос не будет принят приемником.
MPI_sendrecv: отправляет сообщение и ожидает ответа (по сути аналогично RPC)
В целом MPI поддерживает большое число функций (более 100), предназначенных для организации сетевых взаимодействий в многомашинных вычислительных системах (вычислительных кластерах).
Слайд 83Операторы (примитивы) MPI.
Прием сообщений.
Операция MPI_recv вызывается для приема сообщения и
блокирует запустивший процесс до прихода сообщения.
Существует также и асинхронный
вариант этой операции под именем MPI_irecv, вызовом которого получатель показывает, что он готов к приему сообщений. Получатель может проверить, имеются ли пришедшие сообщения, или заблокироваться в ожидании таковых.
Слайд 84Причина поддержки MPI большого числа вариантов взаимодействия
Причина поддержки такого
разнообразия вариантов взаимодействия состоит в том, что разработчики систем MPI
должны иметь все возможности для оптимизации производительности многомашинных вычислительных систем (MIMD – системы по классификации Флина).
Семантика коммуникационных примитивов MPI не всегда проста, и иногда замена различных примитивов никак не влияет на правильность программы.
Слайд 85Приложения MPI против Клиент-сервер
Процессы в параллельных системах на базе MPI
действуют более независимо, подобно пирам в одноранговых системах.
Коммуникации могут обеспечивать
обмен сообщениями в нескольких направлениях.
Коммуникации в системах клиент сервер являются более структурированными.
Слайд 86Сохранная связь на основе сообщений.
ориентированный па сообщения промежуточный уровень
(Message-Oriented
Middleware - MOM)
Слайд 87Системы очередей сообщений
Системы очередей сообщений создают расширенную поддержку асинхронной сохранной
связи.
Смысл этих систем заключается в том, что они предоставляют возможность
промежуточного хранения сообщений, не требуя активности во время передачи сообщений ни от отправителя, ни от получателя.
Их существенное отличие от сокетов Беркли и интерфейса MPI состоит в том, что системы очередей сообщений обычно предназначены для поддержки обмена сообщениями, занимающего минуты, а не секунды или миллисекунды.
Слайд 88Модель очередей сообщений
Основная идея, лежащая в основе систем очередей сообщений,
состоит в том, что приложения общаются между собой путем помещения
сообщений в специальные очереди.
Эти сообщения передаются по цепочке коммуникационных серверов и в конце концов достигают места назначения, даже в том случае, если получатель в момент отправки сообщения был неактивен.
На практике большинство коммуникационных серверов напрямую соединены друг с другом. Другими словами, сообщение обычно пересылается непосредственно на сервер получателя.
В принципе каждое приложение имеет собственную очередь, в которую могут посылать сообщения другие приложения. Очередь может быть прочитана только связанным с ней приложением, при этом несколько приложений могут совместно использовать одну очередь.
Важный момент в системах очередей сообщений СОСТОИТ В ТОМ, ЧТО отправитель обычно в состоянии гарантировать только попадание сообщения — рано или поздно — в очередь получателя. Никакие гарантии относительно того, будет ли сообщение действительно прочитано, невозможны, это полностью определяется поведением получателя.
Подобная семантика определяет слабосвязанное взаимодействие. Именно поэтому у получателя нет необходимости быть активным в то время, когда сообщение пересылается в его очередь.
Слайд 89Варианты слабосвязанных взаимодействий с использованием очередей
Отправитель и получатель могут выполняться
абсолютно независимо друг от друга.
На самом деле, как только
сообщение поставлено в очередь, оно будет оставаться в ней до удаления, независимо от того, активен его отправитель или его получатель.
Возможны следующие варианты:
a) отправитель и получатель в ходе всего процесса передачи сообщения находятся в активном состоянии.
b) активен только отправитель, в то время как получатель отключен, то есть находится в состоянии, исключающем возможность доставки сообщения. Тем не менее отправитель все же в состоянии отправлять сообщения.
c) комбинация из активного получателя
и пассивного отправителя. В этом случае получатель может прочитать сообщения, которые были посланы ему ранее, наличия работающих отправителей этих сообщений при этом совершенно не требуется.
d) вариант когда система сохраняет и передает сообщения, даже при неработающих отправителе и получателе.
Слайд 90Базовый интерфейс очереди
Сообщения в принципе могут содержать любые данные. Единственно
важный момент — они должны быть правильно адресованы.
На практике
адресация осуществляется путем предоставления уникального в пределах системы имени очереди, в которую направляется письмо.
В некоторых случаях размер сообщений может быть ограничен, несмотря на то, что, возможно, базовая система в состоянии разбивать большие сообщения на части и собирать их обратно в единое целое абсолютно прозрачно для приложений.
Эффект подобного подхода — В ТОМ, что базовый интерфейс, предоставляемый приложениям, в результате можно сделать очень простым.
Слайд 91Функции базового интерфейса очереди
Примитив put вызывается отправителем для передачи сообщения
базовой системе, где оно будет помещено в соответствующую очередь. Это
неблокирующий вызов.
Примитив get — это блокирующий вызов, посредством которого авторизованный процесс может извлечь самое старое сообщение из определенной очереди. Процесс блокируется только в том случае, если очередь пуста. Варианты этого вызова включают в себя поиск в очереди определенного сообщения, например, с использованием приоритетов или образца для сравнения.
Неблокирующий вариант представлен примитивом poll. Если очередь пуста или искомое сообщение не найдено, вызвавший этот примитив процесс продолжает свою работу.
И, наконец, большинство систем очередей сообщений поддерживают также процесс вставки дескриптора функции обратного вызова (callback function), которая автоматически вызывается при попадании сообщения в очередь (примитив notify).
Обратные вызовы могут быть также использованы для автоматического запуска процесса, который будет забирать сообщения из очереди, если ни один процесс в настоящее время не запущен. Подобное поведение обычно реализуется при помощи демона на стороне получателя, который постоянно проверяет очередь на наличие входящих сообщений и поступает в соответствии с результатами проверки.
Слайд 92Общая архитектура системы очередей сообщений
На практике это означает, что она
должна поддерживать базу данных (возможно, распределенную) имен очередей (queue names)
в соответствии с их сетевым местоположением, как показано на рис.
Это отображение полностью аналогично использованию системы доменных имен (DNS) для электронной почты Интернета. Так, например, для отсылки почты на логический почтовый адрес steen@cs.vu.nl почтовая система запрашивает у DNS сетевой адрес (то есть IP-адрес) почтового сервера получателя, чтобы затем использовать его для передачи сообщений.
Важно понимать, что набор очередей разнесен по множеству машин.
Соответственно,
для того чтобы система очередей сообщений могла перемещать сообщения, она должна поддерживать отображение очередей на сетевые адреса.
Слайд 93Управление очередями в распределенных системах
Очереди управляются менеджерами очередей (queue managers).
Обычно менеджер очередей взаимодействует непосредственно с отправляющими и принимающими сообщения
приложениями.
Существуют, однако, и специализированные менеджеры очередей, которые работают как:
маршрутизаторы, или ретрансляторы.
Слайд 94Ретрансляторы очередей
Ретрансляторы перенаправляют приходящие сообщения другим менеджерам очередей.
Ретрансляторы могут
быть удобны по нескольким причинам. Так, во многих системах очередей
сообщений не существует общих служб именования, которые могли бы динамически поддерживать отображение имен на адреса. Вместо этого топология сети с очередями сделана статической, а каждый менеджер очередей имеет копию отображения очередей на адреса.
В крупномасштабных системах очередей сообщений подобный подход легко может привести к трудностям в управлении сетью.
Другой причиной использования ретрансляторов является их способность производить вторичную обработку сообщений. Так, например, в целях безопасности или защиты от сбоев может быть необходимо ведение журнала сообщений.
Специальный тип ретрансляторов, в состоянии работать как шлюз, преобразуя сообщения в удобный для получателя вид.
И, наконец, ретрансляторы могут использоваться для групповой рассылки. В этом случае входящее сообщение просто помещается в каждую из исходящих очередей.
Слайд 95Маршрутизаторы очередей
Этот подход схож с ранней конструкцией системы МВоnе поверх
Интернета, в которой обычные пользовательские процессы конфигурировались для маршрутизации групповых
рассылок.
Сегодня маршрутизаторы сами поддерживают групповые рассылки и необходимость в оверлейных групповых рассылках сильно сократилась.
Когда отправитель А помещает в локальную очередь сообщение для получателя В, это сообщение передается на ближайший маршрутизатор R1.
При этом маршрутизатор знает, что делать с этим сообщением, и передает его в направлении В. Так, R1 может понять по имени 5, что сообщение следует передать на маршрутизатор R2.
Таким образом, при добавлении или удалении очередей обновление информации потребуется только маршрутизаторам, в то время как остальным менеджерам очередей достаточно будет знать только местоположение ближайшего маршрутизатора.
Следовательно, маршрутизаторы могут помочь в создании масштабируемых систем очередей сообщений.
Однако по мере роста сети очередей сообщений становится ясно, что ручное конфигурирование невозможно при больших размерах сети.
Единственным решением будет использование динамической схемы маршрутизации, такой же как в компьютерных сетях.
Слайд 96Брокеры сообщений
Важнейшей областью применения систем очередей сообщений является интеграция существующих
и новых приложений в единые согласованные распределенные информационные системы.
Интеграция
требует, чтобы приложения понимали сообщения, которые они получают, т.е. управляемые сообщения должны иметь тот формат, которого ожидает получатель.
Альтернатива состоит в том, чтобы принять единый формат сообщений, как это было сделано с традиционными сетевыми протоколами.
К сожалению, этот подход для систем очередей сообщений в общем случае неприменим. Проблема состоит в уровне абстракций, которыми оперируют эти системы. Единый формат сообщений имеет смысл, только если набор процессов, использующих этот формат, в реальности достаточно однотипен.
В системах очередей сообщений преобразование производится на специальных узлах сети массового обслуживания, известных под названием брокеров сообщений
(message brokers).
Брокер сообщений работает как шлюз прикладного уровня в системе очередей сообщений.
Его основная задача — преобразование входящих сообщений в формат, который понимается целевым приложением.
Для системы очередей сообщений брокер сообщений — это просто еще одно приложение
Слайд 97Сервисы MOM
Сервисы MOM хорошо зарекомендовали себя в сильно распределенных приложениях,
используемых в гетерогенной сети с медленными и ненадежными соединениями. Это,
во-многом, достигается благодаря поддержке уровней «качества обслуживания»:
надежная доставка сообщений (reliable message delivery) — система MOM гарантирует, что в процессе обмена ни одно сообщение не будет утеряно;
гарантированная доставка сообщений (guaranteed message delivery) — сообщение доставляется адресату немедленно или через заданный промежуток времени, не превышающий определенного значения (в случае, если сеть в данный момент не доступна);
застрахованная доставка сообщений (assured message delivery) — каждое сообщение доставляется только один раз.
Слайд 98Виды сервисов МОМ
Очереди сообщений представляют собой мощный, гибкий и в
то же время простой механизм межпрограммного взаимодействия.
Помимо приведенной, можно сказать
классической, схемы с очередями, разработаны и используются сервисы MOM с непосредственной передачей сообщений и на основе подписки.
Системы с непосредственной передачей сообщений (message passing) используют логическое сетевое соединение для обмена сообщениями между взаимодействующими приложениями. Эта схема удобна в тех случаях, когда клиенты и серверы сообщений используются в сильно связанной сетевой инфраструктуре и синхронизированы по времени.
Сервисы MOM, обслуживающие клиентов по подписке/публикации (publish&subscribe) работают по принципу, напоминающему почтовую рассылку: одно приложение публикует информацию в сети, а другие подписываются на эту публикацию для получения необходимых данных. Взаимодействующие таким способом приложения полностью независимы друг от друга, что представляет возможности динамической реконфигурации всей распределенной системы.
Слайд 99API и протоколы систем очередей сообщений
Брокер сообщений – это
приложение промежуточного слоя работающее как шлюз прикладного уровня в системе
очередей сообщений.
Как и любое приложение брокер сообщений может вызываться с помощью API – прикладного программного интерфейса.
В тоже время к брокер сообщений должен поддерживать какой-нибудь протокол , обеспечивающий сетевое взаимодействие между вызывающей и принимающей сторонами.
В простейшем случае это может быть уникальный протокол работающий на основе стека TCP/IP.
Слайд 100API с поддержкой Message Oriented Middleware (MOM)
Java Message Service (JMS)
API - это API с поддержкой Java Message Oriented Middleware
(MOM) для отправки сообщений между двумя или несколькими клиентами. JMS является частью платформы Java, Enterprise Edition.
Подобные цели преследовал проект OpenMAMA (Open Middleware Agnostic Messaging API), который является легковесным уровнем интеграции для систем построенных на основе МОМ.
Слайд 101Протоколы МОМ
Среди таких протоколов можно выделить следующие.
MQTT (Message Queue
Telemetry Transport ) – упрощенный сетевой протокол, работающий поверх протоколов
транспортного уровня,
AMQP (Advanced Message Queuing Protocol) – протокол обмена сообщениями между компонентами системы,
XMPP- (Extensible Messaging and Presence Protocol) – расширяемый протокол обмена сообщениями и данными о присутствии,
STOMP (Simple/Streaming Text Oriented Messaging Protocol) – потоковый тексто-ориентированный протокол обмена сообщениями.
Слайд 102AMQP Advanced Message-Queuing Protocol
AMQP (Advanced Message Queuing Protocol) обеспечивает взаимодействие
между клиентами и брокерами (промежуточным ПО для обмена сообщениями). Он
создан для того, чтобы путем стандартизации сообщений предоставить возможность широкому кругу различных приложений и систем работать вместе независимо от их внутренней структуры.
Брокер – это приложение, реализующее модель AMQP, которое принимает соединения клиентов для маршрутизации сообщений и т.п.
Сообщение – это единица передаваемых данных (включая полезные данные и атрибуты сообщения).
Потребитель – приложение, которое получает сообщения из очередей.
Производитель – приложение, которое отправляет сообщения в очередь через обмен.
Примечание: AMQP не определяет полезную нагрузку сообщений, потому протокол может передавать разные типы данных.
Слайд 103Основные компоненты AMQP
Модель AMQP, которая предоставляет способы приема, маршрутизации, хранения
сообщений, добавления сообщений в очередь и их обработки, основана на
четких определениях следующих компонентов:
Точка обмена: часть брокера (то есть сервер), которая получает сообщения и направляет их в очереди.
Очередь сообщений: именованный объект, с которым связаны сообщения и откуда их получают потребители.
Привязки: правила распространения сообщений из точек обмена в очереди.
Слайд 104Использование системной шины для интеграции приложений созданных для разных программно-аппаратных
платформ
Пример сценария развертывания, показывающий межплатформенный обмен сообщениями с использованием служебной
шины и протокола AMQP 1.0
Поддержка протокола AMQP 1.0 в Azure Service Bus означает, что с эффективным двоичным протоколом предоставляемые сервисной шиной возможности очередей и обмена сообщениями с публикацией/подпиской у брокера можно использовать на различных платформах.
Слайд 105
Коммуникации ориентированные на передачу потоков (Stream-Oriented Communication)
Слайд 106Коммуникации ориентированные на передачу потоков
Виды связи RPC, RMI, МОМ –
все они основываются на обмене дискретными данными.
Для данных этого типа
временные характеристики их доставки не влияют на корректность, а только на производительность обработки.
Коммуникации на основе потоков предполагают, что содержимое сообщений должно быть доставлено с определенной скоростью, так как от этого зависит корректность его представление.
Например, аудио- и видео данные.
Для воспроизведения звука необходимо, чтобы выборки аудиопотока проигрывались в том же порядке, в котором они представлены в потоке данных, и с интервалами ровно по 1/44100 с. Воспроизведение с другой скоростью создаст неверное представление об исходном звуке.
Слайд 107Понятие среды переноса информации
Под средой понимается то, что несет информацию.
Сюда могут входить среды передачи и хранения, среда представления, например
монитор, и т. д. Важнейшая характеристика среды — способ представле
Так, текст обычно кодируется символами ASCII или Unicode. Изображения могут быть представлены в различных форматах, например GIF или JPEG. Аудиопотоки в компьютерных системах могут кодироваться, например, с помощью 16-битных выборок, использующих импульсно-кодовую модуляцию.
В непрерывгюй среде представления {continuous representation media) временные соотношения между различными элементами данных лежат в основе корректной интерпретации смысла данных.
В отличие от непрерывной среды дискрет7шя среда представления (discrete representation media), характеризуется тем, что временные соотношения между элементами данных не играют фундаментальной роли в правильной интерпретации данных. Типичными примерами дискретной среды являются представления текста и статических изображений, а также объектный код и исполняемые файлы.
Слайд 108Поток данных
Для обмена критичной ко времени передачи информацией распределенные системы
обычно предоставляют поддержку потоков данных (data streams, или просто streams).
Поток данных есть не что иное, как последовательность элементов данных.
Потоки данных применимы как для дискретной, так и для непрерывной среды представления.
Так, каналы UNIX или соединения TCP/IP представляют собой типичные примеры дискретных потоков данных (байт-ориентированных).
Воспроизведение звукового файла обычно требует непрерывного потока данных между файлом и устройством воспроизведения.
Временные характеристики важны для непрерывных потоков данных. Для поддержания временных характеристик часто приходится выбирать между различными режимами передачи.
Слайд 109Асинхронный и синхронный режимы передачи
В асинхронном режиме передачи (asynchronous transmission
mode) элементы данных передаются в поток один за другим, но
на их дальнейшую передачу никаких ограничений в части временных характеристик не вводится. Это традиционный вариант для дискретных потоков данных. Так, файл можно преобразовать в поток данных, но выяснять точный момент окончания передачи каждого элемента данных чаще всего бессмысленно.
В cuнхронном реэжииме передачи (synchronous transmission mode) для каждого элемента в потоке данных определяется максимальная задержка сквозной передачи.
Если элемент данных был передан значительно быстрее максимально допустимой задержки, это не важно. Так, например, датчик может с определенной частотой измерять температуру и пересылать эти измерения по сети оператору.
Слайд 110Изохронный режим передачи
При изохронном режиме передачи (isochronous transmission mode) необходимо,
чтобы все элементы данных передавались вовремя. Это означает, что передача
данных ограничена максимально, а также минимально допустимыми задержками, также известными под названием предельного дрожания.
Изохронный режим передачи, в частности, представляет интерес для распределенных систем мультимедиа, поскольку играет значительную роль в воспроизведении аудио- и видеоинформации.
Слайд 111Простые и комплексные потоки данных
Простой поток данных (simple stream) содержит
только одну последовательность данных.
Комплексный поток данных (complex stream) состоит
из нескольких связанных простых потоков, именуемых вложенными потоками данных (substreams).
Взаимодействие между вложенными потоками в комплексном потоке часто также зависит от времени.
Так, например, стереозвук может передаваться посредством комплексного потока, содержащего два вложенных потока, каждый из которых используется для одного аудиоканала.
Важно отметить, что эти два вложенных потока постоянно синхронизированы. Другими словами, элементы данных каждого из потоков должны передаваться попарно для получения стереоэффекта.
Слайд 112Передача потока данных по сети
При передаче данных через сеть процесс-источник
может читать данные из аудиофайла и пересылать их, байт за
байтом, по сети. Приемник может быть процессом, по мере поступления выбирающим байты и передающим их на локальное устройство звуковоспроизведения.
В распределенных мульти-медийных системах можно реализовать прямое соединение между источником и приемником (а).
Также , видеопоток, создаваемый камерой, может напрямую передаваться на дисплей (б).
Слайд 113Групповая передача потоков
Другая ситуация имеет место в зависимости от того,
имеется у нас всего один источник или приемник или мы
можем организовать многостороннюю связь.
Наиболее частая ситуация при многосторонней связи — присоединение к потоку данных нескольких приемников. Другими словами, осуществляется групповая рассылка потока данных нескольким получателям.
Главной проблемой групповой рассылки потоков данных являются разные требования
разных приемников к качеству потока.
Слайд 114Потоки данных и качество обслуживания
Временные зависимости и другие нефункциональные требования
обычно выражаются
в виде требований к качеству обслуживания {Quality of Sewice,
QpS).
Эти требования описывают, что должны сделать базовая распределенная система и сеть для того, чтобы гарантировать, например, сохранение в потоке данных временных соотношений.
Требования QoS для непрерывных потоков данных в основном характеризуются временными диаграммами, объемом и надежностью.
Слайд 115Специфика QoS
Требования QoS могут быть выражены по-разному. Один из подходов
— предоставить точную спецификацию передачи (flow specification), содержащую требования по
пропускной способности, скорости передачи, задержке и т. п.
Слайд 116Алгоритм
корзины элементарных пакетов
Спецификация передачи приведенная выше сформулирована в понятиях алгоритма
корзины элементарных пакетов, который описывает, каким образом поток формирует сетевой
трафик.
Основная идея состоит в том, что элементарные пакеты генерируются с постоянной скоростью. Элементарный пакет содержит фиксированное число байтов, которые приложение намерено передать по сети. Элементарные пакеты собираются в корзину, емкость которой ограничена.
После переполнения корзины элементарные пакеты просто пропадают. Каждый раз, когда приложение хочет передать в сеть элемент данных размером N, оно должно извлечь из корзины столько элементарных пакетов, чтобы их суммарный размер был не менее N байт. То есть, например, если каждый элементарный пакет N имеет длину k байт, приложение должно удалить из корзины как минимум N/k элементарных пакетов.
![Звуки [ Г ], [ Г ' ]](/img/tmb/7/641721/126d2193ce288c820a428ffd0ebbf728-800x.jpg)
