Oracle Media Server:
предоставление потребителям интерактивного доступа к данным мультимедиа*)

Эндрю Ларсен, Джефри Олкин, Марк Портер

Oracle Media Server Development , alaursen@oracle.com, jolkin@oracle.com, maporter@oracle.com


2. Введение

3. Обзор системы
4. Архитектура Oracle Media Server
5. Сервер потоков реального времени
6. Media Net
7. Заключение
8. Благодарности

В настоящее время большая часть данных на больших серверах - это структурированные данные, хранящиеся в традиционных БД. Сети основаны на локальных сетях (LAN), амплитуда рабочих мест - от простых терминалов до мощных рабочих станций. Пользователь - корпоративен, а разработчик приложений - профессионал в области управления информационными системами (MIS - Management Information System).

С введением широкополосной связи в домах и применением техники более чем 100-кратного сжатия появляется новая форма сетевых приложений. Структурированные данные по-прежнему важны, но громадное количество данных стало неструктурированным: аудио, видео, потоки новостей и т.д. Пользователь в большинстве своем является потребителем. Самым распространенным устройством клиента становится бытовой телевизор. Разработчик приложений превращается в сценариста, режиссера или видеоинженера.

Oracle Media Server предоставляет доступ ко всем стандартным типам данных, содержащимся в реляционных и текстовых базах Oracle. Кроме того, мы разработали сервер потоков реального времени, который поддерживает хранение и проигрывание аудио- и видеоданных. Media Server также обеспечивает доступ к данным, представленным либо в виде файлов, либо как большие двоичные объекты (образы, исполнительные модули, и т.д.).

Oracle Media Server обеспечивает платформу для распределенной архитектуры клиент-сервер и доступ к данным по ассиметричным сетям реального времени. Сервисный механизм позволяет расщеплять приложения таким образом, что устройства клиента (интерактивные телеустройства, персональные цифровые помощники и т.д.) могут сфокусироваться на представлении данных, в то время как специальные службы, работающие на распределенном серверном комплексе, обеспечивают доступ к данным при помощи механизма сообщений или облегченного RPC (удаленного вызова процедур).

2. Введение

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

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

Последнее десятилетие развития компьютерной технологии привело к появлению недорогого оборудования для клиентов с персональным программным обеспечением (ПО), масштабируемого оборудования для сервера со сложным ПО управления данными и всевозможных аппаратных средств для гетерогенных сетей со сложным сетевым ПО. Однако надежда иметь в будущем легко разделяемые и легко доступные данные, в основном, не оправдалась. Большая часть ПО - однопользовательское и слишком простое, или же оно позволяет разделять ресурсы, но степень этого разделения выливается в сравнительно большие накладные расходы при работе с ним. Интерактивная работа потребителя в сети - это попытка обеспечить простой доступ к беспрецедентному количеству разделяемых данных. Oracle Media Server предоставляет основу для такой попытки.

3. Обзор системы

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

oms01.gif

Сервер состоит из любого числа компьютеров, связанных в сеть произвольным образом. Сети, связывающие клиентов и серверы, - несимметричны, с высокой скоростью передачи в направлении нисходящего потока. Устройства клиента сегодня в основном предназначены для интерактивного телевидения и обобщенно называются интерактивными телеустройствами. Другие классы устройств (PDA, видеотелефоны и т.д.) для сетей, ориентированных на потребителей, станут значимыми в ближайшем будущем.

3.1. Сети

Основная общая черта сетей, развернутых в настоящее время для интерактивного телевидения, - это асимметричная скорость передачи. Для нисходящего потока - передачи от сервера к устройству клиента - скорость передачи колеблется в пределах от минимума в 1.5 Мбит/с (скорости обмена данными класса DS1) до 45 Мбит/с (скорости обмена класса DS3). Для восходящего потока - передачи от устройства клиента к серверу - скорость передачи может быть более скромной, колеблясь от 9600 бит/c до 64 Кбит/с. Скорость передачи будет возрастать в обоих направлениях, но, по всей видимости, останется сильно асимметричной, т.к. основная часть информации течет по направлению к заказчику.

Три типа физической передачи определяют три типа используемых сетей:

  • ADSL (Asymmetric Digital Subscriber Loop - Ассиметричная Цифровая Петля Абонента) обеспечивает 1.5-6 Мбит/с для скорости нисходящего потока - и до 64 Кбит/с в противоположном направлении - по витой медной паре. Наибольшая, достигнутая на сегодня, дистанция передачи составляет 6000 м. Эта технология поддерживает широкополосную связь с миллионами заказчиков по существующим телефонным линиям.
  • Коаксиальный кабель подает надежды на предоставление 500-т каналов1). Кабель обеспечивает полосу пропускания в 450-1000 МГц. При искусной технологии радиочастотной (РЧ) модуляции можно передать до 8 бит на герц. Типичный студийный кабельный вывод для интерактивного телевидения обеспечит полосу пропускания обратного канала в диапазоне от 5 до 50 МГц, передачу аналогового широковещательного сигнала в диапазоне от 50 до 350 МГц, оставшаяся часть полосы пропускания будет выделена одиночным пользовательским нисходящими каналам со скоростью передачи порядка 3-12 Мбит/с. Таким образом, каждому интерактивному пользователю будет назначен виртуальный нисходящий канал в высокочастотной области спектра и соответствующий канал обратной связи в низкочастотной области спектра. Нисходящий канал - это типичный мультиплексный битовый поток с разделением времени и промодулированный по аналоговому каналу (6 МГц для NTSC, и 8 МГц для PAL). Конечно, существует много способов размещения и модуляции доступной полосы пропускания, и пропускная способность может быть резко увеличена при добавлении оптоволокна.
  • ATM (Asynchronous Transfer Mode - Асинхронный режим передачи) к домам посредством смешанных оптоволоконно/коаксиальных сетей обеспечивает максимальную гибкость как для полосы пропускания так, и для адресации. Так как ATM обеспечивает динамическое изменение полосы пропускания, появляется возможность поддержки битовых потоков с переменной полосой пропускания. Так, например, можно обрабатывать фильмы при скорости передачи 3 Мбит/с, спортивные репортажи, закодированные в реальном времени при 8 Мбит/с, и сжатый HDTV при 20 Мбит/с (или какой-либо другой требуемой скорости передачи). ATM также обеспечивает гибкость, т.к. несколько серверов могут быть непосредственно подсоединены к переключателю ATM с очень высокой скоростью передачи; сегодня уже доступны 155 Мбит/с, и через некоторое время эта скорость увеличится до 622 Мбит/с или 1.2 Гбит/с.

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

Транспортный протокол в сети зависит от направления. В восходящем потоке транспортом могут быть протоколы X.25, UDP, RS232 и др. В нисходящем потоке в качестве транспорта выступают пакеты MPEG-2 (Motion Picture Experts Group), битовые потоки MPEG-1, пакеты UDP или другой высокоскоростной протокол.

3.2. Сжатие

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

Несмотря на то, что студийные устройства цифровых лент обеспечивают скорость передачи до 200 Мбит/с, типичный домашний аппарат для интерактивной работы имеет только 1.5-6 Мбит/с при приеме. Таким образом, для передачи по сети содержимое должно быть сжато более чем в 100 раз. Эта высокая степень сжатия не может быть достигнута сжатием без потерь; часть данных должна быть отброшена. Алгоритмы компрессии-декомпрессии (codecs) различаются в том, как они выбирают данные, подлежащие отбрасыванию и сохранению. Схемы сжатия, например, JPEG (Joint Photographic Experts Group), применяют частотные преобразования, такое как DCT (discrete cosine transform - дискретное косинусное преобразование), к изображению, используя свойство пространственной избыточности (соседние пиксели имеют тенденцию к подобию по частоте). К сожалению, для получения изображения, по качеству сопоставимого с видеостандартом VHS для видеомагнитофонов, схеме JPEG необходима скорость передачи данных, по крайней мере, 4 Мбит/с. Эта скорость слишком велика для нижнего предела доступных полос пропускания в сети.

К счастью, видеопоток имеет так же большую временную избыточность (соседние кадры либо одинаковы, либо похожи). Алгоритмы сжатия, такие как MPEG-1 и MPEG-2, принимают во внимание эту избыточночть и убирают ее из данных. Тщательно сжатый с помощью MPEG-1 фильм при скорости в 1.5 Мбит/с сравним по качеству с VHS VCR; при скоростях порядка 4 Мбит/с алгоритм MPEG-2 сопоставим по качеству с лазерным диском; при скоростях данных в 6-8 Мбит/с (в пределах использования систем с ADSL и с коаксиальным кабелем) качество видео - лучше чем лазерный диск.

Если сжатие видео с использованием как временной, так и пространственной избыточности приносит пользу, то сжатие аудио - нет. Так, достигаемый коэффициент сжатия аудиоинформации при качестве, сопоставимым со звуковым компакт-диском, составляет только около 7:1 (сравните с большим чем 100:1 для видео).

Цифровое сжатое видео имеет много преимуществ перед традиционным аналоговым. Например, оно обеспечивает сквозную совместимость между резко различающимися стандартами, такими, например, как PAL и NTSC, совершенные кадры и совершенное многократное воспроизведение содержимого оригинала2). Цифровое сжатие предлагает возможности, недоступные аналоговой записи, такие как улучшения масштабирования при применении MPEG-2, которые позволяют пользователям перемещаться по большим изображениям и даже увеличивать части изображения с большей детализацией.

Цифровое сжатие имеет также и недостатки. С удалением временной избыточности из потока, отдельно взятый кадр не может быть получен без информации о соседних кадрах, необходимой для полного восстановления его содержания. Это затрудняет случайный доступ к внутренним частям потока; переход может быть сделан только в четко определенные точки доступа, меняющиеся обычно со скоростью два кадра в секунду. Это межкадровая зависимость затрудняет также редактирование сжатого видео. Наконец, из-за сложности, заключающейся в определении зависимостей между кадрами, очень сложно сжимать видео в реальном времени. Хотя кодирование видео в реальном времени сегодня возможно, оно дорого и не скоро появится на потребительском рынке. Между тем, домашние видеоконференциии будут ограничены использованием существующей технологии видеотелефонии. Отметим, однако, что декомпрессия в реальном времени проще и может быть выполнена с помощью небольшого количества микросхем.

Фрактальное сжатие - это одна из закрытых (proprietary) технологий видеокомпрессии, которая основывается на непрерывном дублировании базовых форм в изображениях. Эта технология обещает очень хорошие степени сжатия для определенного типа данных, хотя в настоящее время все еще находится в стадии исследования. Фрактальное сжатие не уничтожает межкадровую временную избыточность и, таким образом, лишена указанных выше недостатков. С точки зрения вычислительных затрат, однако, оно очень дорого.

Существуют другие закрытые алгоритмы компрессии-декомпрессии, такие как TrueMotion и Indeo. Так как крупные поставщикии могут вполне оправдано сомневаться в использовании закрытых кодеров-декодеров, телефонные и кабельные компании поддерживают алгоритмы MPEG помимо всех остальных технологий сжатия. В конечном счете, индустрия остановится на таком всеобъемлющем протоколе (envelope protocol), который будет передавать любые сжатые цифровые данные, независимо от их формата. Таким форматом может быть транспорт MPEG-2 или гипермедиа формат, такой как MHEG или Hytime, или это может быть что-то еще не изобретенное.

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

3.3. Устройства

Интерактивное телеустройство (set-top box) - это прибор, объединяющий в себе функции сегодняшних преобразователей аналогового сигнала (настройка и расшифровка) и компьютеров (управление, диалог и отображение). Текущее поколение интерактивных телеустройств имеет четыре основных компонента: сетевой интерфейс, MPEG-декодер, графическая оверлейная плата и генератор представлений.

  • Сетевой интерфейс обеспечивает работу с нисходящим и восходящим интерфейсами через одно или более физическое соединение.
  • Декодер преобразовывает MPEG-закодированные данные в аудио- и видеоданные. В дополнение, MPEG-подсистема может отделять прикладные и управляющие данные из транспортного потока MPEG .
  • Графическая оверлейная плата (graphics overlay) обеспечивает, по крайней мере, одну графическую плоскость, растровые операции и, необязательно, цветное смешивание (chromakey mixing)3).
  • Генератор представлений (presentation engine) состоит из центрального процессора, по крайней мере двух мегабайт памяти, и миниатюрной, операционной системы реального времени. Клиентская часть приложения выполняется на этой подсистеме. Приложение управляется при помощи кнопок мыши или джойстика. В базовом варианте системы клавиатура отсутствует.

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

3.4. Типы данных

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

Типы данных, которые могут быть доступны потребителям, включают в себя: изохронные (isochronous), текстовые, структурированные и большие двоичные изображения.

  • Изохронные данные4) - это первое, что приходит в голову, когда используется термин мультимедиа. В оперативном режиме по запросу будут доступны фильмы, телевидение и музыка. Главная особенность этого типа данных - слишком большой объем, чтобы просто их загрузить и сохранить, они должны распространяться в масштабе реального времени с минимальной буферизацией. Передача аудио и видео в реальное время - необходимое условие успеха потребительских сетей, но, конечно, не достаточное.
  • Оперативные текстовые базы данных обеспечат доступ ко многим терабайтам данных, от текущих потоков новостей до современных романов из популярных журналов. Главная проблема здесь - это ориентирование и поиск в этом море текста с использованием устройств, не имеющих клавиатуры. Oracle Media Server имеет возможность сокращать и классифицировать текст, что поможет сократить количество первоначально отображаемого текста.
  • Большие двоичные объекты (Binary Large Objects - BLOBS) будут использоваться для хранения большого количества различной информации, от растровых изображений до логики приложений, записанной в командных файлах. Тот же протокол, что и для изохронных данных (с добавлением фронтальной проверки и коррекции ошибок), идеально подходит и для BLOBS.
  • Структурированные данные - как хранящиеся в реляционных базах данных - будут активно использоваться так же, как в нынешних корпоративных базах данных, обеспечивая гибкий доступ и гарантию целостности. Очень большие объекты, изохронные и текстовые данные неэффективно хранить в обычных реляционных БД из-за сложного способа поиска и доступа к данным. Например, MPEG-закодированный фильм не будет храниться в реляционной базе данных, но все его атрибуты (режиссер, ведущие актеры, цена и т.д.) - будут.

4. Архитектура Oracle Media Server

oms02.gif

Oracle Media Server предоставляет программный уровень, обеспечивающий функционирование распределенной архитектуры клиент/сервер на описанных выше потребительских сетях. В его основные компоненты входят:

  • сервисная инфраструктура,
  • обширный набор служб,
  • средства доступа к данным,
  • сервер потоков реального времени,
  • передача сообщений и RPC посредством Oracle Media Net.

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

Приложения на сервере (службы) - ориентированы на данные и разрабатывались теми же инструментами, что используются для построения корпоративных баз данных - инструментов моделирования данных, редакторов схем и т.д. Эти службы должны быть встроены надежным и масштабируемым образом.

Приложения со стороны клиента построены при помощи интерактивных, графических авторских средств, которые позволяют скомпоновать оцифрованные элементы (видео, изображения, звуки и т.д.) согласно логике представления для создания среды времени выполнения на интерактивном телеустройстве. Oracle Media Server будет поддерживать среды времени выполнения, обеспечивая такие службы, как загрузка приложения, управление элементами, санкционирование доступа, взаимодействие с потоком (все это описывается далее). Мы считаем, что будет создано намного больше приложений для клиента, чем приложений для сервера. Например, по всей стране может оказаться всего три службы для покупок из дома, которые будут использоваться сотнями клиентских приложений.

Задержка - главная проблема в сети. Именно поэтому данная архитектура позволяет построить распределенные приложения таким образом, что управление их состоянием происходит на устройстве клиента. Для доступа к данным предпочтение было отдано облегченному RPC перед традиционным SQL, чтобы одновременно сократить количество проходящих сообщений и обеспечить более простые интерфейсы служб приложений.

4.1. Сервисная Инфраструктура

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

Для защиты приложений клиентов от деталей реализации сети им не разрешено работать непосредственно с базами данных. Вместо этого, все приложения, разработанные с использованием Media Server, посылают сообщения службам - как стандартным службам, поставляемым вместе с Media Server, так и к созданными потребителями службами Oracle7 - используя Media Net.

Интерфейсы к службам определяются при помощи языка определения интерфейса (Interface Definition Language - IDL). Интерфейс состоит из набора операций, определяющих, что служба может делать. Однажды созданное, определение интерфейса компилируется для генерации заглушек, изолирующих распределенную природу системы от происходящих вычислений. Приложения клиента выполняют операции, осуществляя вызовы удаленных процедур к серверу.

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

4.2. Доступ к данным

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

  • Изохронные данные хранятся в Oracle Media Data Store, "расщепленной" файловой системе реального времени, допускающей параллельный, произвольный доступ к видео и аудио. Интерфейс позволяет осуществлять операции позиционирования в потоках и проигрывать потоки. Все атрибуты, описывающие потоки (название, описание содержимого, формат сжатия, и т.д.), хранятся как структурированные данные в базе данных Oracle7.
  • Текстовые данные хранятся в БД Oracle Text как набор индексированных документов. Интерфейс позволяет найти документы по словам, фразам и даже понятиям. Свойство абстрагирования текста обеспечивается Oracle*Context, продуктом, который может синтаксически анализировать и интерпретировать английский текст, используя сложную лексику и 50000 правил синтаксического анализа.
  • Большие двоичные объекты - хранятся как закрытые типы данных либо в БД Oracle7, либо в Oracle Media Data Store. Как и в случае изохронных данных, все атрибуты BLOBS хранятся как структурированные данные.
  • Структурированные данные хранятся в БД Oracle7 и являются доступными через SQL и PL/SQL (Procedural Language/SQL). Oracle7 обеспечивает распределение, репликацию и параллельный доступ к данным. Выполнение хранимых процедур в защищенной области среды БД обеспечивает отличный механизм для построения надежных служб. Приложение сервера в этой модели состоит из схемы и набора процедур для доступа к данным в схеме (которые могут напрямую быть вызваны от клиента с использованием службы процедур, описываемой ниже).

4.3. Службы ядра

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

  • Изохронная служба: управляет видео и аудиопотоками.
  • Служба соединения: создает и управляет соединениями с клиентом.
  • Служба авторизации доступа: обеспечивает защиту приложения от несанкционированного доступа посредством проверки персонального идентификационного номера.
  • Реляционная служба: обеспечивает доступ к серверу Oracle7 и стандартным реляционным данным.
  • Служба процедур: обеспечивает доступ к процедурам на PL/SQL от интерактивного телеустройства.
  • Служба перемещения информации: обеспечивает перемещение на интерактивное телеустройство новых исполнительных модулей, потоков данных и т.д. не в реальном времени.

4.4. Службы приложения

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

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

4.5. Административные службы

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

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

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

5. Сервер потоков реального времени

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

Даже при наличии планировщика, обеспечивающего отсутствие перегрузок в системе, существует много ограничений на конструкцию и функционирование сервера реального времени. Он должен:

  • обслуживать большое количество параллельных потоков, каждым из которых управляют независимо;
  • быть надежным по отношению к любым мыслимым отказам аппаратуры или программного обеспечения;
  • хранить огромное количество данных и координат перемещения этих данных по различным носителям и различным серверам;
  • распределять полосу пропускания между различными частями системы;
  • быть переносимым на любую возможную серверную платформу.

5.1. Управление потоком

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

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

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

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

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

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

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

5.2. Надежность

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

Несомненно, самым распространенным местом сбоя в изохронном сервере является магнитный дисковод. Это происходит в значительной степени из-за того, что дисководы - единственная часть центральной системы, содержащая движущиеся элементы. Даже при времени наработки на отказ (MTBF) в 1 миллион часов, в системах с большими массивами дисков будут регулярно наблюдаться отдельные отказы. Для системы, оперирующей многими терабайтами и тысячами дисководов, частые выходы дисков из строя могут сделать недоступными большие объемы информации.

Сервер реального времени может обнаруживать и исправлять дисковые сбои без приостановки потока данных реального времени. Используемый подход уникален (и, к сожалению, закрыт, поэтому его подробности не могут быть изложены в данной статье), так как традиционные подходы к дисковой избыточности (например, RAID - Redundant Arrays of Inexpensive Disks, избыточные массивы недорогих дисков) работают со всем, но не с истинным реальным временем. Диски также отключаются много раз в день из-за нарушения температурного режима, профилактических процедур и т.д. Что касается сбоев дисков, то система выдержит эти временные прерывания работы без какого-либо прекращения работы служб реального времени. В любой системе с дисками, которые могут быть заменены в процессе работы, когда Media Server определяет, что диск вышел из строя и должен быть заменен, он (Media Server, прим. перев.) предлагает оператору отключить устройство с плохим диском и включить другое. Затем он запрашивает у планировщика ресурсы для того, чтобы как можно быстрее подключить диск без остановки потока воспроизведения информации. Система обеспечивает два уровня конфигурирования надежности дисков; администратор системы может выбрать размер накладных расходов внешней памяти для защиты как от одновременного сбоя нескольких дисков, так и от сбоя контроллера, обслуживающего несколько дисков. Способность продолжать проигрывание при одновременных отказах и диска и контроллера решает самую трудную проблему надежности, существующую в серверах реального времени.

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

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

Аппаратная и программная избыточность и независимая способность к рестартам - части базовой архитектуры Media Server. Если иметь эти элементы в каждой службе, то сложную систему можно диагностировать и возвращать в рабочее состояние в кратчайшее время.

5.3. Емкость памяти

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

Media Server управляет многоуровневой системой хранения, в которой фильмы могут храниться на различных устройствах, от автономных ленточных накопителей, до оперативных оптических систем, магнитных дисков и, наконец, оперативной памяти (RAM). Учитывая цену на дисководы - порядка 600 долларов/1 Гбайт, мы получим, что двухчасовой фильм при хранении на магнитном носителе стоит 800 долларов. Стоимость этого же фильма, но хранящегося в оперативной памяти, - 40 000 долларов и порядка 50 долларов при хранении на автономных ленточных накопителях. Где находится тот или иной фильм в данный момент времени, определяется сервером, но человек, управляющий сервером, может в любой момент изменить это решение. Когда принято решение о перемещении части содержимого, этот запрос размещается в потоке реального времени так же как и запросы пользователя.

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

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

5.4. Управление полосой пропускания

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

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

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

5.5. Переносимость

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

Требуя наличия только низкоуровневого ядра реального времени, Media Server является переносимым на многие существующие и новые аппаратные платформы. Media Server может быть поставлен на системы широкого спектра, начиная от рабочих станций, обслуживающих небольшое количество потоков, до симметричных мультипроцессорных (SMP) компьютеров и вплоть до массивно-параллельных (MPP) компьютеров, обслуживающих многие тысячи потоков. Кроме того, поскольку система зависит только от механизмов которые, как правило, представлены в любом оборудовании, она еще и независима от операционной системы.

6. Media Net

Media Net обеспечивает коммуникационную основу, которая позволяет службам, разбросанным по гетерогенным, асимметричным сетям, прозрачным образом взаимодействовать между собой. Большей частью, уровень "видимости" сети для серверов приложений и клиентов минимален, т.к. RPC помогает скрывать эти детали.

Oracle Media Net - это реализация 3 (сетевого) и 4 (транспортного) уровней эталонной модели OSI. При этом этот продукт не пытается заменить существующую работу других сетей; вместо этого он увеличивает их возможности при работе с топологией и количественными параметрами трафика, характерными для сетей, ориентированных на потребителя.

6.1. Сетевой уровень

Сеть Media Net состоит из одной или более низлежащих сетей, каждая со своими собственными характеристиками. Топология сети описывается как ориентированный граф с узлами сети (промежуточными или оконечными) в качестве вершин, а в качестве ребер выступают каналы связи (2 уровень OSI).

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

Ребра графа направленны, что означает, что каждый канал связи определяет направление, в котором данные могут посылаться. Некоторые каналы связи двунаправленны. Пользователю Media Net, однако, вся сеть представляется двунаправленной. То есть, если для каких-либо двух вершин, существует цикл в графе, который включает эти две вершины, то соответствующие два узла сети могут быть связаны. Механизмы маршрутизации скрывают детали топологии.

Каналы связи могут быть либо с коммутацией пакетов, либо с коммутацией соединений. Используя канал с пакетной коммутацией, данные могут быть направлены в любое количество оконечных узлов путем указания их адреса. При использовании связи с коммутацией соединений, данные, посланные от одной стороны, могут быть получены только на другой стороне канала связи. Связи с коммутацией соединений могут быть однонаправленными или двунаправленными. Например, X.25, ATM и TCP/IP - двунаправленные каналы связи с коммутацией соединений. Линия T1, транспортирующая данные клиенту, - пример однонаправленного канала связи. UDP/IP и большая часть средств межпроцессной связи (Inter Process Communication - IPC) - примеры каналов связи с коммутацией соединений6). В любом случае, пакет используется как наименьший общий делитель транспорта, т.к. поток байтов может легко быть разделен на пакеты.

6.2. Маршрутизация

Так как пакет может проходить через несколько различных типов сетей нижних уровней, каждая из которых имеет свою схему адресации, Media Net определяет свое собственное независимое адресное пространство. Это скрывает множество различных типов используемых адресаций для каждого типа каналов связей.

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

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

oms03.gif

Для идентификации подсети используется префикс адреса. Чем длиннее префикс, тем яснее степень детализации подсети. Подсети могут быть произвольным образом отображены на процессы и компьютеры. Например, отдельный процесс может содержать целую подсеть.

На рисунке, приведенном выше, узлу A требуется послать сообщение узлу по адресу 12.34.12.22. Сначала он посылает пакет к шлюзу для подсети 12.34.0.0, который отправляет пакет дальше к шлюзу для подсети 12.34.12.0. Этот шлюз направляет пакет к конечной точке места назначения. Заметьте, что адрес на самом деле определяет конкретный канал связи, а не узел, так один узел может иметь несколько адресов. Облака на рисунке символизируют различные типы сетей более низких уровней.

Решения о маршрутизации принимаются только в момент, когда пакет движется через точку соединения одного типа канала связи с другим. Например, так как IP-сеть ведет себя как один транзитный участок (см. рис. ниже), наличие шлюза Media Net необходимо только тогда, когда пакет должен войти или покинуть IP-сеть. Так как нет необходимости в замене существующей сетевой маршрутизации, ресурсы сети могут быть использованы очень эффективно. В полностью гомогенной двунаправленной сети никаких шлюзов не потребуется, и возможности Media Net по обеспечению маршрутизации не будут использованы.

oms04.gif

6.3. Адресация

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

Когда образуется новый узел, он должен получить адрес в Media Net для своей идентификации. Кроме того, он может иметь известный адрес, который он должен сообщить7). Запрос на получение адреса усложняется тем, что каналы передачи данных в сети могут быть однонаправлеными, а широковещательная сетевая передача (например, передача по Ethernet) в большинстве случаев не доступна.

Для того чтобы узел получил адрес в Media Net, он должен знать канал передачи данных, через который он сможет достичь сервер адресов и, подключившись к которому, он может ожидать ответа. Этот нисходящий канал, в действительности, и формирует адрес.

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

На рисунке предполагается, что сервер адресов 1 получил запрос от устройства клиента по последовательному каналу. Клиент определил линию T1 как канал нисходящего потока. К сожалению, линия T1 не подключена к машине, где функционирует сервер адресов 1; получилось так, что она подключена к другой машине, которая подсоединена к первой посредством Ethernet. Сервер адресов 1 посылает запрос адреса через Ethernet к серверу адресов 2, который выделяет адрес и посылает сообщение-ответ по нисходящему каналу.

oms05.gif

Media Net способен переслать запрос адреса необходимым образом, потому что шлюзы имеют информацию друг о друге и о типах каналов связи, к которым они подсоединены.

Зачем все это нужно? Затем, что адрес, который в конце концов будет присвоен каналу связи, должен принадлежать к подсети, которая идентифицирует соответственного адресата.

Предположим, что клиент запросил второй адрес, но на этот раз описал последовательный канал (теперь двунаправленный) как канал нисходящего потока. На этот раз сервер адресов 1 может выделить адрес сам, так как он непосредственно подключен к последовательному каналу. Клиент теперь имеет второй адрес, никак не связанный с первым. Это приводит к важному выводу: только сервер адресов, подключенный к каналу связи, можетправильно адресовать этот канал.

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

6.4. Надежная система сообщений

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

Надежность реализована на основе стратегии прямого подтверждения с повторной передачей при тайм-ауте. Однако, характеристики и использование сети делают ее неудобной для оценки тайм-аута. Рассмотрим линию T1 с пропускной способностью в 1.5 Мбит/с. Вся полоса пропускания может быть доступна для трафика данных вплоть до начала приема пользователем видео. Затем полоса пропускания, необходимая для передачи данных, внезапно уменьшается до 20 Кбит/с с типичным MPEG-сжатием8). Рассмотрим другую крайность: пользователь PDA, переместившийся из беспроводной в проводную связь, подключившись к гнезду телефонной сети. В этом случае доступная полоса пропускания резко увеличится.

Транспортный уровень должен быть способен адаптироваться к этим изменениям для того, чтобы обеспечить надежную и эффективную передачу. Средства TCP/IP для решения этих проблем не эффективны, потому что они базируются на существовании соединения. Так как основной трафик данных в таких сетях - связь без установления логического соединения (по причинам, описанным ниже), необходимо использовать другое решение.

Принцип, лежащий в основе решения - тот же, что и для TCP/IP: если время прохождения - время, прошедшее с момента посылки сообщения до получения подтверждения, - резко отличается от ожидаемого времени прохождения, мы можем предположить, что доступная полоса пропускания хотя бы одного звена сети изменилась.

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

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

Воплотится ли идея информационной супермагистрали, описанной в популярных материалах прессы, в этом десятилетии или в следующем - неважно. Что важно, так это то, какая сетевая инфраструктура, строящаяся сегодня, поможет потребителям получить похожие интерактивные возможности прямо из дома. Эта инфраструктура дополняется новыми алгоритмами сжатия видеоинформации, которые обеспечивают высококачественную видео и аудиоинформацию при низких скоростях передачи и могут быть довольно недорого декодированы в домашних условиях. Вместе они образуют коммерческую среду по обеспечению домашней аппаратурой с программами, распространяемыми по сети в различных вариациях традиционной модели клиент/сервер. Эта коммерческая среда связана с предоставлением набора продуктов средств информации (фильмов, музыки, и т.д.) для получения дохода от приложений с большей визуализацией. Эти приложения будут создаваться и развиваться до тех пор, пока система не сформирует полную модель интерактивности потребителя, а также сбора информации и ее фильтрации.

Oracle Media Server предоставляет архитектуру, в которой такая модель потребителя может развиваться. Предлагая структуру обслуживания, которая поддерживает разработку сервер-приложений, Media Server позволяет разработчикам сконцентрироваться на создании приложений, ориентированных на media, таких как интерактивная покупка товаров, новости, игры, исследования и образование. Oracle Media Net позволяет этим приложениям поддерживать прозрачную связь по сложным асимметричным современным сетям. Помимо архитектуры служб, изохронного сервера и традиционных методов доступа к данным, посредством RPC предоставляется содержательная информационная среда для потребителя.

Версии 1 и для Oracle Media Server, и для Oracle Media Net существуют уже сегодня и применяются в интерактивных телевизионных сетях как кабельных, так и основанных на ADSL. Все вышеописанное - часть этой реализации ПО. Версия 2 Oracle Media Net будет обеспечивать облегченную аутентификацию пользователя на основе передачи сообщений и поддержку корпоративных сетей. Версия 2 для Oracle Media Server будет обеспечивать средства обработки объектных запросов на сервере.

8. Благодарности

Авторы хотят поблагодарить других членов команды разработки: Фарзада Назема (Farzad Nazem), Уильяма Бэйли (William Bailey), Джеффри Сасна (Jeffrey Sussna), Марка Моора (Mark Moore) и Роба Лэнгхорна (Rob Langhorne).

Особая признательность Джону Зассману (John Zussman), Уильяму Бейли (William Bailey), Франку Чену (Frank Chen), Майку Кари (Mike Carey) и Шелю Финкельштейну (Shel Finkelstein) за своевременный просмотр статьи и замечательные советы по ее улучшению.


*) Переведено и опубликовано из Proceedings of the ACM SIGMOD International Conference, May 1994, с разрешения ACM и авторов.

(c) 1994 ACM


1) Концепция 500 каналов вводит в заблуждение: в них будут входить широковещательные каналы и интерактивные каналы. Обычно, интерактивный канал будет использоваться только одним потребителем.

2) Производственные студии в настоящее время исследуют вопросы возможности создания совершенных копий содержимого потребителем. MPEG-2 обеспечивает шифрование и защиту от копирования та транспортном уровне.

3) chromakey mixing - эффект, позволяющий накладывать видео на конкретный цвет на графической плоскости (карты погоды в выпусках новостей используют эту технологию).

4) Изохронность относится к данным, содержащим временной элемент (таким как аудио или видеопотоки). Термин "поток реального времени" является синонимом.

5) Oracle Media Objects - среда авторизации и поддержки устройств клиента, обсуждение которой выходит за рамки данной статьи.

6) Может показаться необычной ссылка на эти протоколы как на каналы связи, поскольку все они содержат несколько уровней стека OSI, но напомним, что Media Net не подменяет механизмы существующей сети. Так, IP-сеть выглядит как один участок для Media Net.

7) На практике, известные адреса используются только для серверов имен и системных процессов, которые должны продолжать работу даже в случае отказа серверов имен.

8) Из-за специальных характеристик данных реального времени, их передача за пределы каналов связи Media Net происходит эффективно. Тем не менее, влияние этой среды на передачу данных очень существенно.