Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

2.4.

Связь посредством сообщений

141

правляемые сообщения должны иметь тот формат, которого ожидает получа-

тель.

Проблема подобного подхода в том, что каждый раз, когда в систему добавля-

ется новое приложение, оно привносит в нее свой специфический формат сооб-

щений и каждый потенциальный получатель должен научиться понимать этот

формат, на случай, если он получит сообщение от этого нового приложения.

Альтернатива состоит в том, чтобы принять единый формат сообщений, как

это было сделано с традиционными сетевыми протоколами. К сожалению, этот

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

состоит в уровне абстракций, которыми оперируют эти системы. Единый фор-

мат сообщений имеет смысл, только если набор процессов, использующих этот

формат, в реальности достаточно однотипен. Если набор приложений, состав-

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

нороден (а так обычно и бывает), то самым лучшим единым форматом будет

простая последовательность байтов.

Несмотря на то что для отдельных прикладных областей можно определить

свои единые форматы сообщений, общий подход состоит в том, чтобы научиться

существовать в мргре разнообразных форматов, стараясь предоставить средства

для максимально простого преобразования сообщений из одного формата в дру-

гой.

В системах очередей сообщений преобразование производится на специаль-

ных узлах сети массового обслуживания, известных под названием

брокеров

со-

общений

(message brokers). Брокер сообщений работает как шлюз прикладного

уровня в системе очередей сообщений. Его основная задача

—

преобразование

входящих сообщений в формат, который понимается целевым приложением. За-

метим, что для системы очередей сообщений брокер сообщенрш

—

это просто

еще одно приложение, как показано на рис. 2.26. Другими словами, брокер сооб-

щений обычно не считается неотъемлемой частью системы сообщений.

База данных с правилами

Клиент-отправитель Брокер сообщений преобразования Клиент-получатель

г—^

ОС

-л

\—

Программа-

брокер

П'

' ^

" 'к KrJixuVv.lv:;^^^^^^^

Й Й Й Щ |-f| Уровень

1 1т1 II 11 Ы ыочередей!

)

ОС

—

—1

—

1 ^

ос|

Сеть

Рис, 2.26. Обобщенная организация брокера сообщений в системе очередей сообщений

Брокер сообщений может просто переформатировать сообщения. Предполо-

жим, например, что входящее сообщение содержит таблицу базы данных, записи

142 Глава 2. Связь

в которой разделены специальным разделителем, а поля в записи имеют извест-

ную фиксированную длину. Если целевое приложенное рассчитано на другой раз-

делитель записей и переменную длину полей, то для преобразования сообщений

в формат, используемый приложением-получателем, можно использовать бро-

кер сообщений.

В более совершенном варианте брокер сообщений может выполнять обязан-

ности шлюза прикладного уровня, осуществляя, например, преобразование почто-

вых сообщений между сетью Х.400 и Интернетом. В этих случаях часто невозмож-

но гарантировать, что вся информация, содержащаяся в пришедшем сообщении,

действительно будет преобразована в соответствующие части исходящего сооб-

щения. Другими словами, возможно, нам пррщется смириться с частичной поте-

рей информации в ходе преобразования [9, 204].

Сердцем брокера сообщений является база данных с правилами, определяю-

щими, каким именно образом сообщение в формате X конвертируется в сообще-

ние в формате У. Проблема состоит в определении правил. Большинство броке-

ров сообщений поставляются в комплекте со сложными утилитами определения

правил, но в их основе по-прежнему лежит ручной ввод правил в базу данных.

Правила могут формулироваться на специальном языке преобразований, но в боль-

шинстве брокеров сообщений возможно также программное преобразование с ис-

пользованием стандартных языков программирования. Установка брокера сооб-

щений

—

это обычно весьма непростая задача.

Замечание по системам очередей сообщений

Обдумывая то, что мы говорили по поводу систем очередей сообщений, мы при-

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

Системы электронной почты обычно реализуются посредством набора почтовых

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

пользователей соединены с сервером напрямую. Маршрутизация обычно отсут-

ствует, поскольку системы электронной почты могут непосредственно использо-

вать базовые транспортные службы. Так, например, в почтовом протоколе SMTP,

используемом в Интернете

[360],

сообщения пересылаются путем установления

прямого ТСР-соединения с принимающим почтовым сервером.

Системы электронной почты особенно похожи на системы очередей сообще-

ний своей направленностью на предоставление непосредственной поддержки ко-

нечным пользователям. Это объясняет, например, почему множество приложе-

ний для поддержки групповой работы основаны непосредственно на системах

электронной почты

[234].

Кроме того, системы электронной почты могут иметь

очень специфические свойства, например способность автоматической фильтра-

ции сообщений, поддержку специальной базы данных сообщений (например,

для быстрого поиска сохраненных сообщений) и т. д.

Вообще же системы очередей сообщений предназначены не только для под-

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

организация сохранного взаимодействия между процессами, безразлично, запус-

кают эти процессы пользовательские приложения, обслуживают доступ к базе

данных, осуществляют вычисления или делают что-то еще. Такой подход приво-

2.4.

Связь посредством сообщений 143

дит к различиям

в.

требованиях к системам очередей сообщений и «чистым» сис-

темам электронной почты. Так, например, системы электронной почты обычно

не обеспечивают гарантированной доставки сообщений, приоритетов сообще-

ний, средств протоколирования, эффективных групповых рассылок, выравнива-

ния загрузки, защиты от сбоев и пр.

Поэтому системы очередей сообщений общего назначения включают широ-

кий спектр приложений, в том числе приложений электронной почты, рабочих

потоков, средств групповой работы и пакетной обработки. Однако может быть

наиболее важная область применения

—

это интеграция наборов баз данных или

приложений баз данных (возможно, сильно распределенных) в информацион-

ную систему с множеством баз данных. По этой теме можно порекомендовать

работы [337, 416]. Так, запрос, затрагивающий несколько баз данных, может ну-

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

базам. Системы очередей сообщений помогают предоставлять основные возмож-

ности упаковки каждого из подзапросов в сообщение и их направления к соот-

ветствующим базам данных. Другие средства связи, обсуждаемые в этой главе,

подходят для этого значительно хуже.

2.4.4. Пример

—

IBM MQSehes

Чтобы нам было легче понять, как реально работают системы очередей сообще-

ний, рассмотрим конкретную систему, а именно MQSeries компании IBM

[169].

Эта система приобрела популярность в относительно традиционной для IBM об-

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

ки больших баз данных. Важнейшая область применения MQSeries

—

обработка

финансовых данных.

Обзор

Базовая архитектура сети массового обслуживания MQSeries весьма проста

(рис.

2.27). Все очереди управляются

менеджерами

очередей {queue managers).

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

пересылку их другим менеджерам очередей. Кроме того, менеджер очередей отве-

чает за обработку входящих сообщений, извлекаемых им из базовой сети и сохра-

няемых в соответствующих входных очередях.

Менеджеры очередей попарно соединены каналами

сообщений (message

chan-

neb),

которые представляют собой абстракцию соединений транспортного уровня.

Канал сообщений

—

это ненаправленное надежное соединение между отправляю-

щим и принимающим менеджерами очередей, по которому передаются находя-

щиеся в очереди сообщения. Канал сообщений на базе Интернета, например,

реализуется в виде соединения TCP. Каждый из двух концов канала сообщений

управляется агентом канала

сообщений

(Message

Channel

Agent,

MCA). Отправ-

ляющий агент MCA обычно только проверяет исходящие очереди на наличие

в них сообщений, упаковывает их в пакеты транспортного уровня и пересылает

по соединению, соответствующему принимающему агенту МСА. Основная зада-

144

Глава 2. Связь

ча принимающего агента МСА

—

отслеживать приход пакетов, извлекать из них

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

Клиент-отправитель

Таблица

маршрутизации

Очередь

отправки

Программа

Клиентская очередь

получения Клиент-получатель

Интерфейс

очереди

сообщений

—^—

Программа

i'-!-!y''^>i:i;i'^:'ij

Заглушка

Вызовы RPC

(синхронные)

Передача сообщений

(асинхронная)

К другим удаленным

менеджерам сообщений

Рис. 2.27. Обобщенная организация системы очередей сообщений IBM MQSeries

Менеджеры очередей могут быть скомпонованы с каким-либо процессом в еди-

ное приложение, управляющее очередями. В этом случае очереди скрываются от

приложений за стандартным интерфейсом, но непосредственная работа прило-

жения с очередями может оказаться более эффективной. Другим вариантом ор-

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

разных машинах. В этом случае приложениям предоставляется такой же ин-

терфейс, как и при размещении менеджеров очередей на одной с ними машине.

Однако сам интерфейс реализуется в виде заместителя, который связан с менед-

жером очередей традиционной синхронной связью на базе RPC. Таким образом,

система MQSeries в своей основе сохраняет модель, согласно которой доступ

имеется только к локальным по отношению к приложениям очередям сооб-

щений.

Каналы

Каналы сообщений представляют собой важный компонент системы MQSeries.

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

Из этой очереди выбираются сообщения, которые следует переслать на другой

конец канала. Передача по каналу может происходить только в том случае, если

активны как отправляющий, так и принимающий агенты МСА.

Существует несколько способов инициировать канал, альтернативных запус-

ку обоих агентов МСА вручную, и некоторые из них мы сейчас рассмотрим.

Одной из альтернатив является прямой запуск приложением своего конца

канала путем активизации принимающего или передающего агента МСА. Одна-

ко с точки зрения прозрачности это не слишком привлекательная альтернатива.

2.4.

Связь посредством сообщений 145

Более интересным подходом к запуску

передающего

агента МСА является кон-

фигурирование очереди отправки канала на изменение состояния триггера при

помещении в очередь первого сообщения. Этот триггер связывается с обработчи-

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

отправки.

Другой альтернативой является запуск МСА по сети. Так, если одна сторона

канала уже активна, она может послать управляющее сообщение, требующее за-

пуска другого агента МСА. Это управляющее сообщение посылается демону,

просматривающему общедоступный адрес той машины, на которой мы хотим за-

пустить второй агент МСА.

Каналы прекращают свое существование автоматически после того, как в те-

чение определенного времени в очередь отправки не поступит ни одного сообще-

ния.

Каждый из агентов МСА имеет связанный с ним набор атрибутов, которые

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

в табл. 2.4. Значения атрибутов принимающего и передающего агентов МСА

должны быть совместимыми. Обычно агенты МСА договариваются об их значе-

ниях перед запуском канала. Так, например, оба агента МСА должны, очевидно,

поддерживать один и тот же транспортный протокол. Примером необсуждаемо-

го атрибута может быть очередность передачи сообщений

—

та же, в которой со-

общения поступают в очередь отправки, или иная. Если один из агентов МСА

запрашивает отсылку по алгоритму FIFO, другой обязан выполнить это требова-

ние.

Примером обсуждаемого атрибута может быть максимальная длина сообще-

ния, величина которой просто выбирается по минимальному значению этого ат-

рибута для обоих агентов МСА.

Таблица 2.4. Некоторые атрибуты агента канала сообщений

Атрибут Описание

Тип транспорта Используемый транспортный протокол

Доставка FIFO Определяет, что доставка сообщений осуществляется

в том же порядке, что и посылка

Длина сообщения Максимальная длина одного сообщения

Установка числа Максимальное число повторений при запуске удаленного

повторений агента МСА

Попытки доставки Максимальное число попыток МСА поместить полученное

сообщение в очередь

Передача сообщения

Для передачи сообщения одним менеджером очередей другому (возможно, уда-

ленному) необходимо, чтобы каждое сообщение несло в себе адрес назначения.

Для этого используется заголовок сообщения. Адрес в MQSeries образован из

двух частей. Первая часть состоит из имени менеджера очередей, которому это

сообщение должно быть доставлено, а вторая часть

—

это имя очереди назначе-

ния, сообщающее этому менеджеру, к какой очереди добавлять сообщение.

146 Глава 2. Связь

Кроме адреса получателя необходимо также определить маршрут, которым

должно следовать сообщение. Описание маршрута производится путем задания

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

Нет необходимости задавать в сообщении полное описание маршрута. Напом-

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

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

определим, какому соседнему менеджеру очередей будет передано это сооб-

щение.

В большинстве случаев маршруты явно сохраняются в таблицах маршрутиза-

ции внутри менеджеров очередей. Запись в таблице маршрутизации представля-

ет собой пару

(destQM,

sendQ), где destQM

—

имя менеджера очередей, получаю-

щего сообщение, а sendQ

—

имя локальной очереди отправки, к которой следует

добавлять сообщения для этого менеджера. Запись в таблице маршрутизации

в MQSeries называется

псевдонимом

(alias).

Возможно, сообщению до прихода к адресату придется миновать несколько

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

очередей получает сообщение, он просто извлекает из заголовка сообщения имя

менеджера очередей, которому адресовано сообщение, и просматривает таблицу

маршрутизации, отыскивая локальную очередь отправки, в которую следует до-

бавить это сообщение.

Важно понять, что каждый менеджер очередей имеет уникальное в пределах

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

менеджера очередей. Проблемы могут появиться в случае смены менеджера оче-

редей или изменения его имени, это повлияет на все приложения, посылающие

ему сообщения. Эту потенциальную проблему можно ослабить путем использо-

вания в качестве имен менеджеров очередей локальных

псевдонимов (local

alias).

Псевдоним, определенный в менеджере очередей

МУ,

—

это другое имя менедже-

ра очередей М2, доступное только для приложений, работающих с М1. Псевдо-

ним позволяет использовать для очереди другое имя (логическое) даже при смене

менеджера очередей, отвечающего за данную очередь. Изменение имени менед-

жера очередей означает смену его псевдонима во всех менеджерах очередей. При

этом на приложениях это никак не отразится.

Принцип использования таблиц маршрутизации и псевдонимов иллюстрирует

рис.

2.28. Так, например, приложение, соединенное с менеджером очередей QMA,

может ссылаться на удаленный менеджер очередей, используя его локальный

псевдоним

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

истинное место назначения, каковым оказывается менеджер очередей QMC.

Маршрут на QMC ищется в таблице маршрутизации, согласно которой сообще-

ния для

QMC

должны добавляться к очереди отправки SQ1, которая использует-

ся для пересылки сообщений менеджеру очередей QMB. Последний с помощью

своей таблицы маршрутизации пересылает сообщение менеджеру QMC.

Руководствуясь таким подходом к маршрутизации и присвоению псевдони-

мов,

мы приходим к относительно простому прикладному программному интер-

фейсу, который называется интерфейсом очередей сообщений (Message Queue

Interface, MQI). Наиболее важные примитивы MQI собраны в табл. 2.5.

2.4.

Связь посредством сообщений 147

Таблица Таблица

псевдонимов маршрутизации

LA1 QMC

LA2 IQMD

QMB

QMC

QMD

SQ1

SQ2

QMA

Таблица

псевдонимов

LA1 QMA

LA2 IQMD

1=1

SQ1

Таблица

маршрутизации

QMA

QMC

QMD

SQ1

QMB

Таблица

маршрутизации

QMA

QMC

QMB

SQ1

SQ2

SQ1

SQ2

Таблица

псевдонимов

QMD

LA1

LA2

QMA

QMC

Таблица

маршрутизации

QMA

QMB

QMD

SQ1

Рис. 2.28. Обобщенная организация сети очередей MQSeries с использованием

таблиц маршрутизации и псевдонимов

Таблица 2.5. Примитивы MQI для системы IBM MQSeries

Примитив Описание

MQopen

MQclose

MQput

MQget

Открыть очередь (возможно, удаленную)

Закрыть очередь

Поместить сообщение в открытую очередь

Получить сообщение из локальной очереди

Для помещения сообщения в очередь приложение вызывает примитив MQopen,

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

некоего менеджера очередей. Менеджер очередей может быть указан с использо-

ванием локально доступного псевдонима. Независимо от того, является или нет

очередь получения реально удаленной, она абсолютно прозрачна для приложе-

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

можно вызвать примитив MQopen.

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

Когда приложение заканчивает свою работу с очередью, оно может закрыть ее

вызовом примитива MQclose.

Сообщения могут быть записаны в очередь или считаны из нее путем исполь-

зования соответственно примитивов

MQput

MQget.

В принципе сообщения извле-

кают из очереди на основании их приоритета. Сообщения с одинаковым приори-

тетом извлекаются из очереди по принципу первым пришел — первым ушел

(FIFO), то есть дольше всех находящиеся в очереди сообщения извлекаются

первыми. Кроме того, можно запросить конкретное сообщение. И наконец,

MQSeries предоставляет средства для уведомления приложений о приходе сооб-

щений. Это позволяет приложениям не опрашивать постоянно очередь на пред-

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

148 Глава 2. Связь

2.5. Связь на основе потоков данных

Модели взаимодействия, обсуждавшиеся выше, касались обмена более или менее

независимыми, законченными порциями информации. Примерами таковых яв-

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

сообщениями между приложениями в системах очередей сообщений. Характер-

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

в какой конкретно момент времени оно происходит. Несмотря на то, работает

система очень быстро или очень медленно, это никак не сказывается на коррект-

ности ее работы.

Однако существуют формы взаимодействия, в которых временные характе-

ристики имеют решающее значение. Рассмотрим, например, поток аудиоданных,

состоящий из последовательности 16-битных выборок, каждая из которых пред-

ставляет собой амплитуду звуковой волны в импульсно-кодовой модуляцир!.

Предположим также, что поток аудиоданных имеет качество компакт-дисков,

а это значит, что исходный звук был оцифрован с частоторт 44 100 Гц. Для вос-

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

в том же порядке, в котором они представлены в потоке данных, и с интервалами

ровно по

1/44100

с. Воспроизведение с другой скоростью создаст неверное пред-

ставление об исходном звуке.

В этом разделе мы рассмотрим вопрос о том, какие средства могут предло-

жить нам распределенные системы для работы с информацией, критичной к вре-

менным характеристикам передачи, такой как видео- и аудиопотоки. Различные

сетевые протоколы для взаимодействия на базе потоков данных рассматривают-

ся в

[192].

В [434] имеется исчерпывающее введение в вопросы мультимедиа, ча-

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

2.5.1.

Поддержка непрерывных сред

Поддержка обмена критичной к временным характеристикам передачи информа-

ции часто сводится к поддержке непрерывных сред. Под средой понимается то,

что несет информацию. Сюда могут входить среды передачи и хранения, среда

представления, например монитор, и т. д. Важнейшая характеристика среды

—

способ

представления

информации. Другими словами, как информация кодиру-

ется в компьютерной системе? Для различных типов информации используются

различные представления. Так, текст обычно кодируется символами ASCII или

Unicode. Изображения могут быть представлены в различных форматах, напри-

мер GIF или JPEG. Аудиопотоки в компьютерных системах могут кодироваться,

например, с помощью 16-битных выборок, использующих импульсно-кодовую

модуляцию.

непрерывгюй

среде

представления {continuous representation

media) времен-

ные соотношения между различными элементами данных лежат в основе кор-

ректной интерпретации смысла данных. Мы уже давали пример получения зву-

ка при воспроизведении аудиопотока. В качестве другого примера рассмотрим

представление движения. Движение может быть представлено в виде серии кар-

2.5. Связь на основе потоков данных 149

тинок, причем последовательно идущие картинки должны воспроизводиться

в течение одинакового срока Г, обычно составляющего 30-40 мс на картинку.

Правильное воспроизведение требует не только показа картинок в нужной по-

следовательности, но и поддержания постоянной частоты показа

—

^/Г картинок

в секунду.

В отличие от непрерывной среды

дискрет7шя

среда представления (discrete

representation

media), характеризуется тем, что временные соотношения между

элементами данных не играют фундаментальной роли в правильной интерпрета-

ции данных. Типичными примерами дискретной среды являются представления

текста и статических изображений, а также объектный код и исполняемые файлы.

Поток данных

Для обмена критичной ко времени передачи информацией распределенные сис-

темы обычно предоставляют поддержку

потоков

данных (data

streams,

или про-

сто streams). Поток данных есть не что иное, как последовательность элементов

данных. Потоки данных применимы как для дискретной, так и для непрерывной

среды представления. Так, каналы UNIX или соединения TCP/IP представляют

собой типичные примеры дискретных потоков данных (байт-ориентированных).

Воспроизведение звукового файла обычно требует непрерывного потока данных

между файлом и устройством воспроизведения.

Временные характеристики важны для непрерывных потоков данных. Для

поддержания временных характеристик часто приходится выбирать между раз-

личными режимами передачи. В асинхронном режиме передачи (asynchronous

transmission

mode) элементы данных передаются в поток один за другим, но на их

дальнейшую передачу никаких ограничений в части временных характеристик

не вводится. Это традиционный вариант для дискретных потоков данных. Так,

файл можно преобразовать в поток данных, но выяснять точный момент оконча-

ния передачи каждого элемента данных чаще всего бессмысленно.

cuHxpowiOM реэ/симе

передачи

(synchronous transmission

mode) для каждого

элемента в потоке данных определяется максимальная задержка сквозной пере-

дачи. Если элемент данных был передан значительно быстрее максимально до-

пустимой задержки, это не важно. Так, например, датчик может с определенной

частотой измерять температуру и пересылать эти измерения по сети оператору.

В этом случае временные характеристики могут вызвать наш интерес, если вре-

мя сквозного прохождения сигнала по сети гарантированно ниже, чем интервал

между измерениями, но никому не повредит, если измерения будут передаваться

значительно быстрее, чем это действительно необходимо.

И, наконец при

изохронном режиме

передачи

(isochronous transmission

mode)

необходимо, чтобы все элементы данных передавались вовремя. Это означает,

что передача данных ограничена максимально, а

также

минимально допустимыми

задержками, также известными под названием

предельного

дрожа7шя.

Изохрон-

ный режим передачи, в частности, представляет интерес для распределенных

систем мультимедиа, поскольку играет значительную роль в воспроизведении

аудио- и видеоинформации. В этой главе мы коснемся только непрерывных по-

токов данных.

150

Глава 2. Связь

Потоки данных могут быть простыми или комплексными. Простой поток

данных

{simple

stream) содержит только одну последовательность данных. Ком-

плексный поток данных (complex

stream)

состоит из нескольких связанных про-

стых потоков, именуемых вложенными потоками данных (substreams). Взаи-

модействие между вложенными потоками в комплексном потоке часто также

зависит от времени. Так, например, стереозвук может передаваться посредством

комплексного потока, содержащего два вложенных потока, каждый из которых

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

потока постоянно синхронизированы. Другими словами, элементы данных каж-

дого из потоков должны передаваться попарно для получения стереоэффекта.

Другим примером комплексного потока данных может быть поток данных для

фильма. Такой поток мог бы состоять из одного видеопотока и двух аудиопото-

ков для передачи стереофонической звуковой дорожки к фильму. Четвертый по-

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

нежели в звуковой дорожке, язык. И вновь необходима синхронизация вложен-

ных потоков. При нарушениях синхронизации нарушается нормальное воспро-

изведение фильма. Ниже мы еще вернемся к синхронизации потоков данных.

Процесс-источник Процесс-приемник

V \.

F~^

—

U Программа

ОС

Поток данных

ОС

Сеть

Камера

=И1

Дисплей

Сеть

Рис. 2.29. Передача потока данных по сети между двумя процессами (а),

между двумя устройствами (б)

Поток данных нередко может рассматриваться в виде виртуального соедине-

ния между источником и приемником. Источник или приемник может быть про-

цессом или устройством. Например, при передаче данных через сеть процесс-ис-

точник может читать данные из аудиофайла и пересылать их, байт за байтом, по

сети. Приемник может быть процессом, по мере поступления выбирающим бай-

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

туацию иллюстрирует рис. 2.29, а, С другой стороны, в распределенных мульти-