MPEG форматы
Реферат - Компьютеры, программирование
Другие рефераты по предмету Компьютеры, программирование
оставляя простой интерфейс к приложению.
На рис. 34 представлена указанная выше концепция. Приложение получает доступ к данным через интерфейс приложения DMIF, вне зависимости от того, откуда получены данные: от широковещательного источника, локальной памяти или от удаленного сервера. Во всех сценариях локальное приложение только взаимодействует через универсальный интерфейс (DAI). Различные варианты DMIF будут затем транслировать запросы локального приложения в специфические сообщения, которые должны быть доставлены удаленному приложению, учитывая особенности используемых технологий доставки. Аналогично, данные, поступающие на терминал (из удаленного сервера, широковещательных сетей или локальных файлов) доставляются локальному приложению через DAI.
Специализированные версии DMIF подключаются приложением апосредовано, чтобы управлять различными специфическими технологиями доставки данных, это, однако прозрачно для приложения, которое взаимодействует только с одним "DMIF фильтром". Этот фильтр отвечает за управление конкретным примитивом DAI в нужный момент.
Концептуально, "настоящее" удаленное приложение доступное через сеть, например, через IP или ATM, ничем не отличается от эмулируемого удаленного приложения, получающего материал от широковещательного источника или с диска. В последнем случае, однако, сообщения, которыми обмениваются партнеры, должны быть определены, чтобы обеспечить совместимость (это сигнальные сообщения DMIF). В последнем случае, с другой стороны, интерфейсы между двумя партнерами DMIF и эмулируемым удаленным приложением являются внутренними по отношению реализации и не должны рассматриваться в этой спецификации. Заметим, что для сценариев получения данных широковещательно и из локальной памяти, рисунок показывает цепочку "Локальный DMIF", "Удаленный DMIF (эмулированный)" и "Удаленное приложение (эмулированное)". Эта цепочка представляет концептуальную модель и не должна отражаться в практической реализации (на рисунке она представлена закрашенной областью).
Рис. 34. Архитектура коммуникаций DMIF
При рассмотрении сценариев с широковещанием и локальной памятью предполагается, что эмулируемое удаленное приложение знает, как данные доставлены/запомнены. Это подразумевает знание типа приложения, с которым осуществляется взаимодействие. В случае MPEG-4, это в действительности предполагает знание идентификатора элементарного потока, дескриптора первого объекта, названия услуги. Таким образом, в то время как уровень DMIF концептуально не знает ничего о приложении, которое поддерживает, в частном случае работы DMIF с широковещанием и локальной памятью это утверждение не вполне корректно из-за присутствия эмулированного удаленного приложения (которое, с точки зрения локального приложения является частью слоя DMIF). При рассмотрении сценария удаленного взаимодействия, слой DMIF ничего не знает о приложении. Введен дополнительный интерфейс DNI (DMIF-Network Interface), который служит для подчеркивания того, какого рода информацией должны обмениваться партнеры DMIF. Дополнительные модули SM (Signaling mapping) служат для установления соответствия между примитивами DNI и сигнальными сообщениями, используемыми в конкретной сети. Заметим, что примитивы DNI специфицированы для информационных целей, и интерфейс DNI в настоящей реализации может отсутствовать. DMIF допускает одновременное присутствие одного или более интерфейсов DMIF, каждый из которых предназначен для определенной технологии доставки данных. Одно приложение может активировать несколько технологий доставки.
Вычислительная модель DMIF
Когда приложение запрашивает активацию услуги, оно использует сервисный примитив DAI, и формирует соответствующую сессию. Реализация DMIF устанавливает контакт с соответствующим партнером (который концептуально может быть либо удаленным, либо эмулируемым локальным партнером) и формирует вместе с ним сетевую сессию. В случае широковещательного и локального сценариев, способ формирования и управления сессией находится вне зоны ответственности данного документа. В случае интерактивного сценария с удаленным сервером, DMIF использует свой сигнальный механизм для формирования и управления сессией, например, сигнальный механизм ATM. Приложения партнеров используют эту сессию для установления соединения, которое служит для передачи прикладных данных, например, элементарных потоков MPEG-4. Когда приложению нужен канал, оно использует примитивы канала DAI, DMIF транслирует эти запросы в запросы соединения, которые являются специфическими для конкретных запросов сетевых реализаций. В случае сценариев широковещания и локальной памяти, метод установления соединения и последующего управления находится за пределами регламентаций MPEG-4. В случае сетевого сценария напротив, DMIF использует свой сигнальный механизм для формирования и управления соединением. Это соединение используется приложением для целей доставки данных.
На рис. 35 предоставлена схема активации верхнего уровня и начало обмена данными. Этот процесс включает в себя четыре этапа:
- Приложение-инициатор посылает запрос активизации услуги своему локальному слою DMIF - коммуникационное соединение между приложением-инициатором и его локальным партнером DMIF устанавливается в контрольной плоскости (1)
- Партнер-инициатор DMIF запускает сетевую сессию с партнером-адресатом DMIF - коммуникационное соединение партнером-инициатором DMIF и партнером-адресатом DMIF устанавливае