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

C. Bouras, V. Kapoulas, D. Miras, V. Ouzounis, P. Spirakis

1 Computer Engineering and Informatics Dept.

Univ. of Patras, 265 00 Patras, Greece

2 Computer Technology Institute

262 21 Patras, Greece

E-Mail: bouras@cti.gr

Автор перевода: Мукимов Ш.С.

Краткий обзор

В этой работе, мы представляем архитектуру для интерактивных распределенных служб мультимедийной информации. Служба состоит из трех основных частей, клиентов, серверов доступа и серверов контента. Клиенты управляют представлением требуемых мультимедийных документов, в то время как также обеспечивают синхронизацию среди различных включенных носителей. Обсуждены специальные политики для синхронизируемого представления мультимедийного управления документами и взаимодействием с пользователем. Серверы доступа авторизовывают пользователей для законного использования службы, в то время как также обеспечивают, различные серверы Контента возможностей поиска управляют транспортировкой мультимедийных документов по широкополосной сети и взаимодействию с пользователем. Предложенная архитектура сохраняет масштабируемость, гибкость и модульный принцип из-за распределенной природы архитектуры, в то время как также приводит к хорошей производительности из-за динамического выделения ресурсов.

1. Введение

В течение последних лет мы испытываем существенное развитие мультимедийных технологий и быстрого прогресса сетевой инфраструктуры. Некоторые технологии предоставления возможности, которые ответственны за этот рост, являются скоростной организацией сети и стандартами протокола связи, стандартами сжатия для изображений и видео, скоростного вычисления и влияния WWW. Эти события делают выполнимыми поставка мультимедийной информации среди мест по сети и способствуют появлению новых заявлений, которые используют многократные СМИ. Продвинутые мультимедийные системы характеризуются интегрированным управляемым компьютером поколением, хранением, коммуникацией, манипуляцией и представлением независимых и timeindependent СМИ с временной зависимостью [7].

Мультимедийную информационную систему можно рассмотреть как ряд функций или услуг, которые намереваются представить конечному пользователю интерактивную информацию, которая призывает множество СМИ, таких как форматированный текст, изображения, слайды, графы, мультипликация, аудио, звук, видео, и т.д., объединенным способом [3]. Эти заявления - полоса пропускания и интенсивная память, таким образом, становится очень важно развить схемы, которые эффективно используют систему и сетевые ресурсы, в то время как одновременно оказывают лучшую услугу пользователям [1,4,5,6]. Чтобы быть успешными, эти заявления должны сделать огромные объемы данных легкодоступными для их пользователей. Чтобы сделать данные, обращающиеся управляемым, информация должна быть распределена через различные сайты [6].

Поскольку число пользователей, которые требуют использовать эти увеличения служб, новые политики для извлечения распределенных мультимедийных данных и по требованию поставка их, должно адресоваться. Эти политики должны поддерживать гибкий доступ к информации, безопасности, конфиденциальности, учету, управлению правами интеллектуальной собственности, анонимности пользователей, считая механизмы, и наконец, распределение ресурсов и управление. Большинство существующих испытаний в области распределенных мультимедийных служб страдает от ограниченной доступности, недостаточной безопасности, низкого уровня интеграции и масштабируемости, неэффективных механизмов распределения ресурсов и политик. В этой газете мы предлагаем архитектуру, которая стремится решать вышеупомянутые проблемы, фокусирующиеся на ondemand предоставлении мультимедийных документов, синхронизируемом представлении их, управлении взаимодействием с пользователем и необходимыми ресурсами. Наша прототипная реализация также обращенным к проблеме функциональной совместимости, определяя обобщенные интерфейсы службы, которые являются протоколом и независимый от сети.

2. Архитектура службы

Архитектура предложенной интерактивной распределенной мультимедийной службы состоит из трех основных частей клиенты, серверы доступа и серверы контента. Функциональность и характеристики основных частей предложенного интерактивного распределенного мультимедиа и службы гиперсреды - следующее:

• Клиенты. Они управляют представлением требуемых документов, обеспечивая синхронизацию среди различных включенных носителей, корректировку опций представления и необходимых ресурсов. Они также связываются с сервером контента, чтобы сообщить о несогласованностях синхронизации, и передать взаимодействия пользователей (получите документ, переместитесь, и т.д.), . Кроме того они также выделяют и управляют необходимыми ресурсами.

• Серверы доступа. они обеспечивают разнообразный набор интерфейсов службы, которыми управляют взаимодействующим и безопасным способом. Эти интерфейсы управляют транзакциями, которые требуют клиенты перед аутентификацией, или примитивы подписки вызваны. В дополнение к вышеупомянутому, серверу доступа обрабатывает разнообразные клиентские запросы согласно различным протоколам информационного поиска.

• Серверы контента. Они поддерживают необходимые ресурсы, получают надлежащие данные от соответствующих баз данных, управляют транспортировкой документа гиперсреды и носителей, включенных в сценарий представления, и корректируют скорости переноса каждого носители. Серверы контента состоят из двух отличных модулей, а именно, мультимедийный сервер и медиасерверы. Сервер мультимедиа гиперсреды управляет транспортировкой мультимедийных сценариев, координирует транспортный процесс каждого носители, корректируя скорости переноса, и также обеспечивает справедливое выделение ресурсов различным соединенным клиентам. Медиасервер управляет транспортировкой соответствующих мультимедийных потоков, и скорректируйте скорости переноса, чтобы сгладить сетевые задержки и аномалии синхронизации.

Пользователи взаимодействуют со службой, используя известный набор функций, которые обеспечены службой прозрачным и дружественным способом. Первоначально, клиент соединен с одним определенным сервером доступа. Сервер доступа по запросу аутентифицирует клиент, и если пользователь - авторизованный, соединение может быть сделано. С этого времени пользователь может представить запросы относительно различных предметов интереса, используя обобщенный и межоперабельный интерфейс. Внутренние детали используемых процедур поиска или определенные детали используемого протокола скрыты от пользователя. Элементы документов, которые соответствуют представленный запрос, переданы клиенту и представлены пользователю. Пользователь может выбрать один документ для того, чтобы просмотреть, и в этом случае надлежащий провайдер контента, в котором тот элемент находится на, проводится. Серверы контента, по запросу, получают требуемый документ гиперсреды от базы данных гиперсреды/мультимедиа, передают его клиенту и упрощают надлежащую транспортировку встроенных объектов носителей, учитывая пространственно-временные отношения среди них. Объекты СМИ получены от соответствующих баз данных и транспортированы посредством различных параллельных соединений с клиентом. Корректировка скоростей переноса каждого носители имеет место, постоянно считая периодические отчеты обратной связи сгенерированными клиентом. На основе этих отчетов транспортировка каждого носители скорректирована, чтобы сгладить сетевые задержки и аномалии синхронизации. Встроенные объекты носителей буферизованы временно в клиенте, и затем они представлены согласно сценарию представления. Серверы доступа, клиенты и серверы контента связываются через широкополосную сеть. Мультимедийные документы хранятся в специализированных базах данных гиперсреды, присоединенных к серверам мультимедиа/гиперсреды, в то время как встроенные объекты носителей находятся на определенных базах данных, присоединенных к медиасерверам, которые могут быть замечены как сетевые распределенные базы данных. Каждый документ гиперсреды описан, используя язык представления. Это описание определяет включенные встроенные объекты носителей, расположение их в соответствующей базе данных носителей, способ, которым они будут представлены пользователю и отношениям синхронизации среди них. Это описание - фактически сценарий представления. Документы могут быть соединены через гиперссылки, формируя сеть документов. Соединенные документы могут храниться в том же или в различных мультимедийных серверах.

3. Клиентские вопросы проектирования

Основные функции, которые клиент предоставляет пользователю, являются соединением со службой, извлечением определенного элемента интереса и просмотром выбранного документа. Характеристики этих компонентов касаются управления мультимедийным потоком, локального управления буферизацией, синхронизируемого представления объектов носителей согласно сценарию представления, управлению ресурсами и размещению взаимодействия с пользователем. В рисунке 1 изображены функциональные компоненты клиента и их взаимодействий. Первоначально, пользователи запрашивают соединиться с определенным сервером доступа, определяющим код доступа. Код доступа - уникальный код, который характеризует определенный клиент. Сервер доступа, используя этот код, аутентифицирует пользователя, ищущего в базе данных авторизованных пользователей. Для каждого клиента сохраняется запись в базе данных авторизованных пользователей. В этой базе данных каждая запись содержит персональные данные о пользователе (например, имя, адрес, телефонный номер, идентификатор кредитной карты, и т.д.) и информация относительно интересов определенного клиента (например, хобби, профессиональный интерес и т.д.). Кроме того запись содержит учетную информацию, детализированная ссылка времени входила в систему система и документы, которые получены в прошлом, а также информация о ценах относительно этих полученных документов. Список гиперссылок к предыдущим полученным документам и программам сохранен локально в сервере доступа. Безопасность и конфиденциальность обеспечены, используя список управления доступом, который соответственно определяет, какой пользователь имеют полномочия получить доступ к определенной единице информации. Для каждой темы или информации явно определен ряд допустимых пользователей, у которых есть доступ к ресурсам.

Рисунок 1: Клиентская Схема Проекта

После аутентификации пользователя и установления соединения, пользователи могут получить доступ к индексной базе данных, чтобы искать интересную тему или запрос на определенный документ от сертифицированного провайдера контента. Сертифицированные провайдеры контента должны гарантировать качество предоставленных услуг, целостности и новизны информации. Индексная база данных содержит информацию о различных темах и данных. Записи в индексной базе данных определяют, в котором сервере контента эти определенные данные находятся на, какого количества это стоит, чтобы получить доступ к этой информации, разрешают ли тому определенному пользователю получить доступ к нему, и маленькое описание о целом гипердокументе. Только описание гипердокумента и сбора, чтобы получить доступ к нему представлено пользователю, в то время как другие поля в записи используются внутренне сервером доступа, чтобы упростить запрос. Когда пользователь запрашивает определенный гипердокумент, с соответствующим сервером контента, где требуемая информация находится на, связываются. Сервер контента, по запросу, получает от базы данных гиперсреды определенный сценарий представления, вперед это клиенту и обновляет базу данных учетной записи, обвиняющую клиент за требуемую информацию. Каждая запись в базе данных учетной записи содержит информацию о требуемом документе, сервер доступа, который запрашивал его, время и дата, этот определенный запрос выпущен и соответствующий заряд.

Клиент, на основе сценария представления оценивает надлежащие ресурсы относительно сети и организации буферизации данных носителей. Особенно, сценарий представления прослежен, и отнесенные объекты носителей определены. Для каждый включенные носители, инициализированы необходимые Сетевые Потоковые Контроллеры (NSCs), в то время как соответствующие буферы носителей зарезервированы. NSCs упрощают входящие пакеты каждого мультимедийного потока, в то время как буферы носителей временно хранят полученные пакеты прежде, чем они будут представлены пользователю. Размер каждого буфера носителей соответственно вычислен, используя несколько параметров, таких как сетевая задержка, пакетная длина, носители, кодирующие стандарт и требуемое качество представления. Длина буферов носителей соответствует времени воспроизведения для каждого объекта носителей, и мы определяем на сей раз как окно времени носителей. Окно времени носителей используется, чтобы сгладить задержки, вставленные сетью, операционной системой и другими факторами. Таким образом опытные задержки влияют (уменьшают) определенное окно времени носителей прежде, чем влиять на качество представления и синхронизации. Для каждого объекта носителей с временной зависимостью с определенными ограничениями представления параллельный потоковый сеанс установлен между клиентом и надлежащим медиасервером. Пакеты данных от детали, которой возражают носители, переданы клиенту через параллельный сеанс и получены соответствующим СНБ. Полученные пакеты непосредственно перемещены в буфер носителей и "ожидают", пока надлежащий момент времени их представления не достигнут. NSCs и менеджеры по Буферу СМИ (MBMs) постоянно контролируют, носители буферизуют размещение и в сочетании с Планировщиком Представления (который контролирует аномалии синхронизации и несогласованности представления), информация обратной связи извлечений, которая объединена с информацией о параметрах соединения (задержка, дрожание, пакетная потеря). Параметры соединения соответственно вычислены информацией, которая встроена в 4 заголовок поставленных пакетов. QoS сообщает, которые периодически передаются серверу контента, содержат все эти статистически измеренные параметры. Эти отчеты фактически отражают качество обеспеченной и представленной информации. Исследуя эти отчеты, сервер гиперсреды/мультимедиа корректирует скорости переноса и качество каждого объекта носителей, который будет поставленным. Представлением требуемого мультимедийного документа управляет Планировщик Представления в сочетании с менеджерами СМИ и MBMs. После предварительной обработки полученного сценария представления, распределения ресурсов и инициализации определенных функциональных модулей, определены playout сроки для каждый, которому возражают отнесенные носители. playout срок каждого объекта носителей определяет время начала представления этого определенного объекта носителей. Кроме того, продолжительность представления, временные и пространственные отношения среди объектов носителей определены. При помощи этой информации Планировщик Представления может расположить представление каждого мультимедийного потока согласно его playout сроку. Прежде, чем представление мультимедийного документа запущено, есть время “установки”, чтобы подать каждый буфер носителей с начальным объемом данных. Эта задержка используется, чтобы преодолеть сетевые несогласованности и управлять взаимодействием с пользователем относительно представления документа. Для каждого объекта носителей в сценарии представления создается параллельный процесс представления, на основе playout срока. Этот процесс активирован каждый раз, когда время начала представления достигло. В продолжении объекты носителей получаются от буферов носителей и питаются при номинальных показателях соответствующему менеджеру СМИ, где они играются/представляются надлежащим устройством. Взаимодействие с пользователем прерывает представление требуемого документа и инициализирует надлежащие меры. Взаимодействие с пользователем - или определенное представление или определенный документ. Представление определенные действия активирует или перезапуск представления или обратное представление. В обоих случаях Планировщик Представления продолжает представление документа с требуемого момента времени, используя данные от буферов носителей и следовательно, никакой разрыв представления не испытан. Размер буферов носителей соответствует временному интервалу представления, равному времени задержки распространения, необходимому для поставки следующих пакетов каждого объекта носителей. Когда Планировщик Представления “достигает” конца буфера носителей, следующие объекты носителей, которые должны быть представлены, уже достигли клиента. Документ определенные взаимодействия может быть: возвратитесь к предыдущему представленному документу, следуйте за гиперссылкой и т.д., как и управляют таким же образом в случае первого требуемого документа. Эти взаимодействия могут быть инициированы любое время во время представления, заставляя представление текущего документа остановиться.

4.Проблемы проектирования сервера доступа

Основные функции, которые обеспечивает сервер доступа, являются авторизацией пользователя, подписки к службе, возможностям поиска и передаче результатов требуемых запросов. Сервер доступа предоставляет обобщенный интерфейс клиентам, согласно которым встроены различные протоколы информационного поиска, в то время как определенные детали скрыты (например, HTTP, SQL, и т.д.). Первоначально, клиент пытается соединиться со службой, чтобы иметь доступ к информации, которая предоставлена в различных провайдерах контента. Сервер доступа, по запросу, вызывает примитивную аутентификацию.

Рисунок 2: Схема проекта сервера доступа

Согласно этому примитиву, ищется когерентная централизованная база данных, чтобы удостовериться, что у пользователя может быть доступ к службе. В случае, если это, пользователь не авторизованный примитивная подписка, вызвано. Пользователь заполняет стандартную форму и представляет его серверу доступа. Новая запись в базе данных авторизованных пользователей создается, в то время как уникальный код доступа отправлен пользователю. Эта новая запись передана к каждому совместному серверу доступа в службе, чтобы получить когерентность к содержанию авторизованной базы данных. После установления соединения пользователь может представить запросы серверу доступа, чтобы получить информацию об определенных thematical модулях. Сервер доступа ищет локально индексную базу данных, чтобы найти все соответствующие элементы, которые удовлетворяют требуемый запрос, в то время как также тот же запрос передан ко всему совместному серверу доступа по той же причине. Это среднее значение, что индексная база данных - распределенная база данных, в которой весь сервер доступа может получить необходимые элементы. Результаты запроса переданы к определенному серверу доступа, который 5 триггеров процедура и затем передала надлежащему клиенту. При помощи этой схемы информация от различных провайдеров контента может быть добавлена локально в индексной базе данных одного сервера доступа, не вызывая дополнительных издержек. Каждый элемент, который соответствует требуемый запрос фактически, содержит информацию метаданных относительно фактического документа, который описывает. В дополнение к этому информация метаданных определяет инициатора мультимедийного документа и провайдера контента, в котором тот документ находится на. При помощи этой информации клиент может непосредственно запросить документ от соответствующего сервера контента. В рисунке 2 проиллюстрированы функциональные модули сервера доступа. Сетевые контроллеры упрощают сетевые определенные действия, в то время как Интерпретатор Запроса управляет взаимодействием с пользователем. Менеджер транзакций управляет надлежащими транзакциями с другими совместными серверами доступа согласно предыдущей описанной процедуре.

5. Проблемы проектирования сервера контента

Основные функции сервера контента являются размещением запросов документа, зарядом требуемой информации, и распределением ресурсов и управлением необходимыми ресурсами. Требуемые документы поставлены по требованию, в то время как целый транспортный процесс корректируется постоянно, чтобы сохранить качество обслуживания на эффективных уровнях. Когда запрос выпущен, мультимедийный сервер оценивает ресурсы, необходимые для транспортировки документов, и вычисляет сценарий потока. Сценарий потока определяет встроенные объекты носителей, когда транспортировка должна запуститься, и которым должна быть скорость переноса. Сценарий потока вычислен, используя сценарий представления, рассматривая пространственно-временные отношения среди различных носителей, текущего состояния сети и доступных ресурсов в сервере доступа. Каждый медиасервер управляет надлежащими ресурсами, используя сценарий потока.

Рисунок 3: Схема проекта сервера контента

Каждый медиасервер, на основе сценария потока, получает соответствующие объекты носителей от базы данных носителей, разделяет данные на пакеты, и согласно четко определенной скорости передачи передает их надлежащему серверу доступа посредством выделенного параллельного соединения. Корректировка скорости передачи каждого, носители имеют место, чтобы встретить ограничения представления и состояние сети. Корректировка сделана, используя периодические отчеты обратной связи, сгенерированные клиентом (отчеты QoS). Взаимодействие с пользователем, относительно операций представления, прерывает текущий процесс транспортировки и вызывает перерасчет сценария потока. Момент точного времени, в который будет перезапущено представление документа, определен. На основе буферных размеров клиент-серверного и сервера доступа соответственно, также определены точные объекты носителей и их ограничения реального времени. В продолжении процесс транспортировки перезапущен согласно новому сценарию потока. При помощи этого подхода минимизированы разрывы, испытанные в представлении. Рисунок 3 иллюстрирует функциональные модули Сервера Контента.

6. Проблемы реализации

Предложенный подход к проектированию был реализован и прототипная версия, которая удовлетворяет вышеупомянутые характеристики и возможности, уже разработаны. Служба протестирована более чем кольцо FDDI на 100 Мбит/с использование 6 комплектов протоколов TCP/IP. Доступ и серверы контента работают на различных Рабочих станциях Unix в то время как клиенты, работающие на PC. Клиенты могут быть или непосредственно соединены к кольцу FDDI или соединены в LAN, который соединен с FDDI.

Мультимедийные документы явно описаны, используя язык разметки гиперсреды, который поддерживает необходимые возможности. Язык разметки предлагает ряд примитивов для представления и синхронизации встроенных объектов носителей и соединения среди документов. Среда выполнения особенно реализована, чтобы интерпретировать и упростить эти примитивы. Для передачи данных мы используем Транспортный протокол реального времени (RTP). RTP - промежуточный протокол, который предоставляет приложению сквозные функции для передачи данных реального времени, такие как аудио и видео. RTP увеличен с Протоколом управления реального времени (RTCP) управляющего протокола, который включает несколько действий, таких как контроль параметров продолжающегося сеанса. RTP не делает quarantee QoS в передаче данных и полагается на сетевые протоколы, чтобы использовать их примитивы передачи. Мы используем заголовок этого пакета, чтобы получить статистические измерения относительно состояния сети (дрожание, пакетная потеря, и т.д.) .

7. Заключения

Мы представили архитектуру для интерактивных распределенных служб мультимедийной информации. Представлены различные проблемы относительно по требованию предоставления мультимедийных документов, распределения ресурсов и управления. Кроме того проблемы относительно синхронизируемого представления мультимедийных документов и управления взаимодействием с пользователем обсуждены. Производительность нашей прототипной реализации довольно хороша из-за динамического выделения и управления необходимыми ресурсами. В дополнение к этому корректировка по требованию, которая процесс поставки согласно состоянию сети также, составляет к достигнутой производительности. Другой ключевой вопрос - уровень масштабируемости и гибкости, которая происходит довольно высоко из-за распределенной природы службы. Мы намереваемся развернуть предложенную архитектуру, чтобы поддерживать онлайн тарифицирующие механизмы и лучшие политики управления ресурсами. Мы также намереваемся соединиться в прототипные примитивы QoS quarantee версии. В настоящее время мы находимся на фазе анализа и спецификации протокола для по требованию предоставление мультимедийных документов по основанным на ATM сетям. В дополнение к этому мы намереваемся портировать нашу прототипную реализацию в находящихся в Corba платформах, в то время как также исследуют потенциал, чтобы включить требования и спецификации DAVIC.

8. Ссылки

[1] Д. П. Андерсон Г. Хомси, “Сервер ввода / вывода СМИ Continous и его Механизмы Синхронизации”. Компьютер, Издание 24, № 10, октябрь 1991, стр 51-57.

[2] Блаковский, Steiwetz, “Обзор Синхронизации СМИ: Эталонная модель, Спецификация и Тематические исследования”. Журнал IEEE на Отобранных областях в Коммуникационном Издании 14, № 1, стр 5-35.

[3] C.Bouras, В. Кэпулас, Д. Мирас, В. Узунис, П. Спиракис, А. Татакис, “По требованию Обслуживание Мультимедиа Гипер-СМИ по Широкополосным сетям”. Пятый IEEE Международный Симпозиум по Высокоэффективному Распределенному Вычислению, Семинар по Центру на Мультимедийной Совместной Окружающей среде, 6-9 августа 1996, Сиракузах, Нью-Йорке, США.

[4] T.D.C. Мало, Д. Венкэтеш, "Метауправление данными клиент-сервер для предоставления Фильмов в Видео по требованию - Система". В Proc. 1-ый Международный семинар на Услугах в Распределенной и Сетевой Окружающей среде, Праге, Чешская Республика, июнь 1994, стр 11-18.

[5] Р. Рэморэо, В. Рамамурти, “Дизайн архитектуры По требованию Видео Поставки Systems:The Spatio-Временная проблема Распределения Хранения”. В Proc. ICC 1991, стр 17.6.1-17.6.5

[6] П. В. Рэнгэн, Х. М. Вин, С. Рамарэзэн, “Проектируя По требованию Мультимедийное Обслуживание”. Коммуникационный Журнал IEEE, Издание 30, № 7, июль 1992, стр 56-64.

[7] Р. Стейнмец Р., К. Нарстедт, “Основные принципы в Мультимедийном Вычислении и Коммуникациях”. Энглвудские Утесы, Нью-Джерси, Prentice-зал, 1995.