Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 40
Текст из файла (страница 40)
Другим примером может быть воспроизведение потока стереозвука,состоящего из двух вложенных потоков, по одному на каждый канал. Правильное воспроизведение требует взаимной синхронизации двух вложенных потоков, несовпадение более чем на 20 мс может исказить стереоэффект.Синхронизация происходит на уровне элементов данных, из которых состоитпоток. Другими словами, мы можем синхронизировать два потока только относительно элементов данных. Выбор элементов данных очень сильно зависит отуровня абстракции представления потока данных. Для разъяснения этого момента рассмотрим аудиопоток (одноканальный) с качеством компакт-диска. Примаксимальной степени детализации поток данных представляется в виде последовательности 16-битных выборок.
При частоте выборки 44 100 Гц синхронизация с другим аудиопотоком может теоретически производиться каждые 23 мс.Для получения высококачественного стереоэффекта оказывается, что синхронизация на этом уровне абсолютно необходима.Однако если мы рассмотрим синхронизацию между аудио- и видеопотокамидля синхронизации артикуляции, обнаружится, что в этом случае можно использовать значительно более грубую детализацию. Как мы говорили, видеокадрыпоказываются с частотой 25 Гц и выше.
Используя широко распространенныйстандарт NTSC с его частотой 30 Гц, мы можем сгруппировать аудиовыборкив логические блоки с временем воспроизведения, равным времени показа видеокадра (33 мс. При частоте выборки звука 44 100 Гц блок аудиоданных будетсодержать 1470 отдельных выборок, или И 760 байт, из расчета 16-битных выбо-2.5. Связь на основе потоков данных157рок). На практике вполне удовлетворительное качество обеспечивается PI большими блоками, по 40 или даже 80 мс [435].Механизмы синхронизацииНу вот, мы и подошли к вопросу о том, как на самом деле обеспечивается синхронизация.
Следует рассмотреть два момента: во-первых, базовые механизмы синхронизации двух потоков данных и, во-вторых, распределение этих механизмовв сетевой среде.Механизмы синхронизации могут рассматриваться с позиций разных уровней абстракции. С точки зрения самого нижнего, синхронизация полностью определяется работой с элементами данных простых потоков. Этот принцип иллюстрирует рис.
2.33. В сущности, здесь показан процесс, который осуществляетоперации чтения и записи в нескольких простых потоках данных, гарантируя приэтом обеспечение ограничений синхронизации.Машина получателяПроцедура, считывающаядва элемента аудиоданных Приложениена каждый элемент ^^^видеоданных>Входящий поток1о•^ОССетьРис.
2.33. Принцип явной синхронизации на уровне элементов данныхРассмотрим, например, фильм, представленный двумя входными потоками данных. Видеопоток содержит несжатые изображения низкого качества с разрешением 320x240 пикселов. Каждый из пикселов при кодировании требует одногобайта, что в сумме приводит к элементам видеоданных размером в 76 800 байт.Предположим, что изображения демонстрируются с частотой 30 Гц, или по 33 мсна изображение. Считаем, что аудиопоток содержит аудиовыборки, сгруппированные в элементы длиной 11 760 байт, каждый из которых, как говорилосьранее, соответствует звуку длительностью 33 мс. Если процесс ввода можетобеспечить скорость 2,5 Мбайт/с, мы можем обеспечить синхронизацию, просточередуя чтение изображений и блоков аудиовыборок каждые 33 мс.Оборотная сторона подобного подхода состоит в том, что приложение можетполностью отвечать за синхронизацию только в том случае, еслР1 оно имеет доступ к механизмам низкого уровня.
Лучше будет предоставить приложенрпо интерфейс, который упростил бы ему управление потоками и устройствами. Относительно нашего примера это будет означать, что видеодрюплей получитинтерфейс управления, с помощью которого сможет управлять частотой воспроизведения изображений. Кроме того, интерфейс предоставит механизм регистра-158Глава 2. Связьции пользовательского обработчика, который будет вызываться каждый раз послеприема очередных k изображений.
Аналогичный интерфейс будет предоставлени устройству воспроизведения звука. Используя эти управляющие интерфейсы,разработчик приложения сможет написать простую программу мониторинга,сравнивающую два заголовка соответствующих потоков данных. Эта программабудет проверять, достаточна ли синхронизация видео- и аудиопотоков и в случаенеобходимости регулировать частоту передачи видео- или аудиоэлементов.Этот последний пример (рис. 2.34) типичен для многих систем мультимедиапромежуточного уровня. В действительности системы мультимедиа промежуточного уровня содержат набор интерфейсов для управления аудио- и видеопотоками,включая интерфейсы управляющих устройств — мониторов, камер, микрофокови т. п.
Каждое устройство и поток данных имеют свои собственные интерфейсыверхнего уровня, в том числе и интерфейсы для уведомления приложенир! о наступлении некоторого события Последние часто используются при написанииобработчР1Ков, предназначенных для синхронизацирг потоков. Примеры подобных интерфейсов можно найти в [65].Машина получателяСистема контролямультимедиа — это частьпромежуточного уровняПриложение сообщаетпромежуточномууровню, что делатьс входящим потокомПромежуточный уровеньпрограммного обеспечения"Входящий потокСетьРис. 2.34.
Принцип синхронизации, поддерживаемойвысокоуровневыми интерфейсамиРаспределение механизмов синхронизации было вторым вопросом, которыймы собирались обсудить. Прежде всего получатель комплексного потока данных, состоящего из требующих синхронизации вложенных потоков, должен точно знать, что ему делать. Другими словами, он должен иметь исчерпывающуюлокальную спецификацию синхронизации. Обычно эта информация предоставляется в неявном виде, путем мультиплексирования нескольких потоков данныхв один, содержащий все элементы данных, в том числе и предназначенные длясинхронизации.Подобный подход к синхронизации используется в потоках MPEG. Стандарты MPEG {Motion Picture Experts Group) содержат набор алгоритмов сжатия видео- и аудиоданных. Существует несколько стандартов MPEG.
MPEG-2, например, был изначально предназначен для сжатия видеоизображения с качествомтипичного телесигнала на скоростях от 4 до 6 Мбайт/с. Согласно этому стандарту в единый поток данных может быть собрано неограниченное количество2.6. Итоги159непрерывных и дискретных потоков. Каждый входящий поток сначала преобразуется в поток пакетов, содержащих отметку времени, базирующуюся на 90-килогерцевых системных часах. Затем эти потоки мультиплексируются в программный поток данных {program stream), состоящий из пакетов переменной длины,объединенных одинаковым базовым временем.
Принимающая сторона демультиплексирует поток и использует метки времени каждого из пакетов в качествеосновы механизма межпотоковой синхронизации.Еще один важный вопрос: где проводить синхронизацию, на передающемконце или на принимающем? Если синхронизацией занимается передатчик, онможет объединить потоки данных в один, содержащий различные типы элементов данных. Рассмотрим вновь поток стереозвука, содержащий два вложенныхпотока, по одному на канал. Мы рассматривали единственную возможность —передачу потоков независимо друг от друга с последующей синхронизацией наприемнике путем попарного объединения выборок.
Ясно, что если задержкив каждом из вложенных потоков данных будут разными, синхронизация окажетсякрайне затруднительной. Значительно лучше объединить вложенные потоки наотправителе. Получившийся в результате поток будет содержать элементы данных, состоящие из пар выборок, по одной на канал. В этом случае приемникудостаточно просто считать элемент данных и разделить его на выборки левогои правого каналов. Задержка для обоих каналов будет абсолютно одинаковой.2.6. ИтогиНаличие мощных и гибких механизмов взаимодействия между процессами является важным для всякой распределенной системы. В традиционных сетевых приложениях связь часто базируется на низкоуровневых примитивах передачи сообщений, предоставляемых транспортным уровнем. Важной особенностью системпромежуточного уровня является предоставляемая ими высокая степень абстракции, благодаря которой описание взаимодействия между процессами на промежуточном уровне значительно проще, чем если бы мы ограничились только интерфейсами транспортного уровня.Одной из наиболее широко используемых абстракций является удаленныйвызов процедур (Remote Procedure Call, RPC).
Сущность RPC в том, что любаяслужба реализуется посредством вызова процедуры, тело которой выполняетсяна сервере. Клиент предоставляет только сигнатуру процедуры, то есть имя процедуры и ее параметры. Когда клиент вызывает процедуру, клиентская реализация, называемая заглушкой, упаковывает значения параметров в сообщение и пересылает его на сервер. Последний вызывает собственно процедуру и возвращаетрезультат, снова в виде сообщения.
Клиентская заглушка извлекает из этого сообщения значение результата и передает его приложению клиента, инициировавшему вызов.Механизм RPC ориентирован на обеспечение прозрачности доступа. Однакоон относительно слабо поддерживает передачу ссылок. В этом смысле удаленные160Глава 2. Связьобъекты более прозрачны. Обращение к удаленным методам (Remote MethodInvocation, RMI) напоминает RPC, но отражает специфику удаленных объектов.Основная разница между ними состоит в том, что RMI позволяет использоватьв качестве параметров ссылки на объекты системы.RPC и RMI предоставляют механизмы синхронной связи, при которой клиент блокируется до получения ответа от сервера. Несмотря на вариации существующих механизмов, в которых жесткая синхронная модель смягчена, нередкоболее удобными оказываются универсальные высокоуровневые модели, ориентированные на передачу сообщений.В моделях передачи сообщений неважно, является ли связь сохранной, также как неважно и то, является ли она синхронной.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
