10.3. Синтетический звук
MPEG-4 определяет декодеры для генерирования звука на основе нескольких видов структурированного ввода. Текстовый ввод Text преобразуется в декодере TTS (Text-To-Speech), в то время как прочие звуки, включая музыку, могут синтезироваться стандартным путем. Синтетическая музыка может транспортироваться при крайне низких потоках данных.
Декодеры TTS (Text To Speech) работают при скоростях передачи от 200 бит/с до 1.2 Кбит/с, что позволяет использовать при синтезе речи в качестве входных данных текст или текст с просодическими параметрами (тональная конструкция, длительность фонемы, и т.д.). Такие декодеры поддерживают генерацию параметров, которые могут быть использованы для синхронизации с анимацией лица, при осуществлении перевода с другого языка и для работы с международными символами фонем. Дополнительная разметка используется для передачи в тексте управляющей информации, которая переадресуется другим компонентам для обеспечения синхронизации с текстом. Заметим, что MPEG-4 обеспечивает стандартный интерфейс для работы кодировщика TTS (TTSI = Text To Speech Interface), но не для стандартного TTS-синтезатора.
10.3.1. Синтез с множественным управлением (Score Driven Synthesis).
Средства структурированного аудио декодируют входные данные и формируют выходной звуковой сигнал. Это декодирование управляется специальным языком синтеза, называемым SAOL (Structured Audio Orchestra Language), который является частью стандарта MPEG-4. Этот язык используется для определения "оркестра", созданного из "инструментов" (загруженных в терминал потоком данных), которые формирует и обрабатывает управляющую информацию. Инструмент представляет собой маленькую сеть примитивов обработки сигналов, которые могут эмулировать некоторые специфические звуки, такие, которые могут производить настоящие акустические инструменты. Сеть обработки сигналов может быть реализована аппаратно или программно и включать как генерацию, так и обработку звуков, а также манипуляцию записанными ранее звуками.
AAC | Advanced Audio Coding – продвинутое кодирование звука |
AAL | ATM Adaptation Layer – адаптационный уровень ATM |
Access Unit | Логическая субструктура элементарного потока для облегчения доступа или манипуляции потоком данных |
ACE | Advanced Coding Efficiency (профайл) – эффективность продвинутого кодирования |
Amd | Поправка |
AOI | Area Of Interest – область интереса |
API | Application Programming Interface – программный интерфейс приложения |
ARTS | Advanced Real-time Simple – простой, продвинутый профайл реального времени |
ATM | Asynchronous Transfer Mode – режим асинхронной передачи |
BAP | Body Animation Parameters – параметры анимации тела |
BDP | Body Definition Parameters – параметры описания тела |
BIFS | Binary Format for Scenes – двоичный формат сцены |
BSAC | Bit-Sliced Arithmetic Coding – побитовое арифметическое кодирование |
CD | Committee Draft – проект комитета |
CE | Core Experiment – центральный эксперимент |
CELP | Code Excited Linear Prediction – линейное предсказание, стимулируемое кодом |
CIF | Common Intermediate Format – общий промежуточный формат |
CNG | Comfort Noise Generator – генератор комфортного шума |
DAI | DMIF-Application Interface – прикладной интерфейс DMIF |
DCT | Discrete Cosine Transform – дискретное косинусное преобразование |
DMIF | Delivery Multimedia Integration Framework - |
DNI | DMIF Network Interface – сетевой интерфейс DMIF |
DRC | Dynamic Resolution Conversion – преобразование с динамическим разрешением |
DS | DMIF signaling – сигнальная система DMIF |
EP | Error Protection – защита от ошибок |
ER | Error Resilient – противостояние ошибкам |
ES | Elementary Stream (элементарный поток): последовательность данных, которая исходит из передающего терминала MPEG-4 Terminal и приходит одному получателю, например, медиа- или управляющему объекту в приемном терминале MPEG-4. Он проходит через один канал FlexMux. |
FAP | Facial Animation Parameters – параметры анимации лица |
FBA | Facial and Body Animation – анимация лица и тела |
FDP | Facial Definition Parameters – параметры описания лица |
FlexMux stream | Последовательность пакетов FlexMux, ассоциированных с одним или более каналов FlexMux, идущих через один канал TransMux |
FlexMux tool | A Flexible (Content) Multiplex tool – гибкое средство мультиплексирования |
GMC | Global Motion Compensation – компенсация общего перемещения |
GSTN | General Switched Telephone Network – общедоступная коммутируемая телефонная сеть |
HCR | Huffman Codeword Reordering – смена порядка кодовых слов Хафмана |
HFC | Hybrid Fiber Coax – гибридный волоконный коаксиал |
HTTP | HyperText Transfer Protocol – протокол передачи гипертекста |
HVXC | Harmonic Vector Excitation Coding – кодирование с гармоническим возбуждением вектора |
IP | Internet Protocol – протокол Интернет |
IPI | Intellectual Property Identification – идентификация интеллектуальной собственности |
IPMP | Intellectual Property Management и Protection – защита и управление интеллектуальной собственностью |
IPR | Intellectual Property Rights – Права интеллектуальной собственности |
IS | International Standard – международный стандарт |
ISDN | Integrated Service Digital Network – цифровая сеть с интегрированными услугами |
LAR | Logarithmic Area Ratio – логарифмическое отношение области |
LATM | Low-overhead MPEG-4 Audio Transport Multiplex: |
LC | Low Complexity – низкая сложность |
LOAS | Low Overhead Audio Stream – аудио поток с низкой избыточностью |
LOD | Level Of Detail – уровень детализации |
LPC | Linear Predictive Coding – линейно-предсказательное кодирование |
LTP | Long Term Prediction – долгосрочное предсказание |
M4IF | MPEG-4 Industry Forum – Промышленный форум MPEG-4 |
MCU | Multipoint Control Unit – многоточечный блок управления |
Mdat | media data atoms – атомы медийных данных |
Mesh | A graphical construct consisting of connected surface elements to describe the geometry/shape of a visual object. - |
MIDI | Musical Instrument Digital Interface – цифровой интерфейс музыкального инструмента> |
MPEG | Moving Pictures Experts Group – Экспертная группа по движущимся изображениям |
MSB | Most Significant Bits - наиболее значимые биты |
OCI | Object Content Information – информационное содержание объекта |
OD | Object Descriptor – дескриптор объекта |
PDA | Personal Digital Assistant – персональный цифровой помощник |
PDU | Protocol Data Unit – Протокольный блок данных |
PSNR | Peak Signal to Noise Ratio – отношение пикового значения сигнала к шуму |
QCIF | Quarter Common Intermediate Format – четвертинный промежуточный формат изображения (видео) |
QoS | Quality of Service – качество обслуживания |
Rendering | The process of generating pixels for display – процесс генерации пикселей для отображения |
RTP | Real Time Transport Protocol – транспортный протокол реального времени |
RTSP | Real Time Streaming Protocol – поточный протокол реального времени |
RVLC | Reversible Variable Length Coding – реверсивное кодирование с переменной длиной |
SA-DCT | shape-adaptive DCT – двойное косинусное преобразование, адаптируемое к форме объекта |
SID | Silence Insertion Descriptor – дескриптор паузы |
SL | Sync(hronization) layer – уровень синхронизации |
SMIL | Synchronized Multimedia Integration Language – интеграционный язык для синхронизованного мультимедиа |
SNHC | Synthetic- Natural Hybrid Coding – синтетико-натуральное кодирование |
SNR | Signal to Noise Ratio – отношение сигнал-шум |
Sprite | Статический спрайт представляет собой возможно большое статическое изображение, описывающие панорамный фон |
SRM | Session Resource Manager – субъект управления ресурсами сессии |
SVG | Scalable Vector Graphics – масштабируемая векторная графика |
T/F coder | Time/Frequency Coder – преобразователь времени в частоту |
TCP | Transmission Control Protocol – протокол управления передачей данных |
TransMux | Общая абстракция для любой схемы транспортного мультиплексирования |
TTS | Text-to-speech – текст в голос |
UDP | User Datagram Protocol – протокол передачи датограмм пользователя |
UEP | Unequal Error Protection - |
UMTS | Universal Mobile Telecommunication System – универсальная мобильная телекоммуникационная система |
VCB | Virtual CodeBook – виртуальная кодовая книга |
Viseme | Выражение лица, сопряженное с определенной фонемой |
VLBV | Very Low Bitrate Video – видео с очень низкой скоростью передачи данных |
VM | Verification Model – верификационная модель |
VOP | Video Object Plane – объектная плоскость видео |
VRML | Virtual Reality Modeling Language – язык моделирования виртуальной реальности |
W3C | World Wide Web Consortium – консорциум WWW |
WD | Working Draft – рабочий черновик (проект) |
WWW | World Wide Web – Всемирная паутина |
XMT | Extensible MPEG-4 textual format – расширяемый текстуальный формат MPEG-4 |
2.2. Системы
Как объяснено выше, MPEG-4 определяет набор алгоритмов улучшенного сжатия для аудио и видео данных. Потоки данных (Elementary Streams, ES), которые являются результатом процесса кодирования, могут быть переданы или запомнены независимо. Они должны быть объединены так, чтобы на принимающей стороне возникла реальная мультимедийная презентация.
Системные части MPEG-4 обращаются к описаниям взаимодействий между аудио и видео компонентами, которые образуют сцену. Эти взаимодействия описаны на двух уровнях.
Двоичный формат для сцен BIFS (Binary Format for Scenes) описывает пространственно-временные отношения объектов на сцене. Зрители могут иметь возможность взаимодействия с объектами, например, перемещая их на сцене или изменяя свое положение точки наблюдения в 3D виртуальной среде. Описание сцены предоставляет широкий набор узлов для композиционных 2-D и 3-D операторов и графических примитивов.
На нижнем уровне, Дескрипторы объектов OD (Object Descriptors) определяют отношения между элементарными потоками, имеющими отношение к конкретному объекту (например, аудио- и видео-потоки участников видеоконференции). OD предоставляют также дополнительную информацию, такую как URL, необходимые для доступа к элементарным потокам, характеристики декодеров, нужных для их обработки, идентификация владельца авторских прав и пр.
Некоторые другие особенности работы системы MPEG-4:
Интерактивно, включая: взаимодействие клиент-сервер; общая модель событий или отслеживание действий пользователя; общая обработка событий и отслеживание взаимодействий объектов на сцене пользователем или с помощью событий, генерируемых на сцене.
Средство объединения большого числа потоков в один общий поток, включая временную информацию (мультиплексор FlexMux).
Средство для запоминания данных MPEG-4 в файле (файловый формат MPEG-4, ‘MP4’)
Интерфейсы для различных терминалов и сетей в виде Java API (MPEG-J)
Независимость транспортного уровня.
Текстовые презентации с международной лингвистической поддержкой, выбор шрифта и стиля, согласование времени и синхронизация.
Инициализация и непрерывное управление буферами приемных терминалов.
Идентификация временной привязки, синхронизация и механизмы восстановления.
Наборы данных, включающие идентификацию прав интеллектуальной собственности по отношению к медиа-объектам.
3.1. Системы
Версия 2 систем MPEG-4 расширяет версию 1, с тем, чтобы перекрыть такие области, как BIFS-функциональность и поддержка Java (MPEG-J). Версия 2 также специфицирует формат файлов для записи содержимого MPEG-4.
4.2. Системы
4.2.1. Advanced BIFS
Продвинутый BIFS предоставляет дополнительные узлы, которые могут быть использованы в графе сцены для мониторирования доступности и управляемости среды, такие как посылка команд серверу, продвинутый контроль воспроизведения, и так называемый EXTERNPROTO, узел, который обеспечивает дальнейшую совместимость с VRML, и который позволяет написание макросов, определяющих поведение объектов. Предусмотрено улучшенное сжатие данных BIFS, и в частности оптимальное сжатие для сеток и для массивов данных.
Рисунок содержит составные медиа-объекты, которые объединяют примитивные медиа-объекты. Примитивные медиа-объекты соответствуют периферии описательного дерева, в то время как составные медиа-объекты представляют собой суб-деревья. В качестве примера: визуальные объекты, соответствующие говорящему человеку, и его голос объединены друг с другом, образуя новый составной медиа-объект.
Такое группирование позволяет разработчикам создавать комплексные сцены, а пользователям манипулировать отдельными или группами таких объектов.
MPEG-4 предлагает стандартизованный путь описания сцен, позволяющий:
помещать медиа-объекты, где угодно в заданной координатной системе;
применять преобразования для изменения геометрического или акустического вида медиа-объекта;
группировать примитивный медиа-объекты для того чтобы образовать составные медиа-объекты;
использовать потоки данных, чтобы видоизменять атрибуты медиа-объектов (например, звук, движущуюся текстуру, принадлежащую объекту; параметры анимации, управляющие синтетическим лицом);
изменять, интерактивно, точку присутствия пользователя на сцене (его точку наблюдения и прослушивания).
Описание сцены строится во многих отношениях также как и в языке моделирования виртуальной реальности VRML (Virtual Reality Modeling language).
7. Согласование
Программа, формирующая почтовое сообщение и соответствующая данной спецификации, должна гарантировать, что любая строка печатных ASCII-символов, не содержащая HT и SP в пределах '*text' или '*ctext', начинается с "=?" и завершается "?=" является корректным 'кодировочным словом'. ("Начинается" означает: в начале тела сразу после LWS, или сразу после "(" для 'кодировочного слова' в пределах '*ctext'; "завершается" означает: в конце тела, непосредственно перед LWS, или непосредственно перед ")" для 'кодировочного слова' в '*ctext'.) Кроме того, любое 'слово' в 'фразе', которое начинается с "=?" и завершается "?=" должно быть корректным 'кодировочным словом'.
Программа, читающая почтовые сообщения, совместимые с данной спецификацией должна быть способна отделить 'кодировочное слово' от 'text', 'ctext', или 'слов', которые согласуются с правилами секции 6, где бы они не встретились в заголовке сообщения. Она должна поддерживать "B"- и "Q"-кодирование для любых символьных наборов, которые она поддерживает. Программа должна быть способна отобразить не кодированный текст, если символьный набор соответствует "US-ASCII". Для символьных наборов ISO-8859-*, программа должна быть способна, по крайней мере, отобразить символы, которые совпадают с ASCII.
9.14.3. Сокрытие ошибок
Сокрытие ошибок (имеется в виду процедура, когда последствия ошибок не видны) является исключительно важным компонентом любого устойчивого к ошибкам видео кодека. Средства аналогичные данному рассмотрены выше, эффективность стратегии сокрытия ошибок в высшей степени зависит от работы схемы ресинхронизации. По существу, если метод ресинхронизации может эффективно локализовать ошибку, тогда проблема сокрытия ошибок становится легко решаемой. Для приложений с низкой скоростью передачи и малой задержкой текущая схема ресинхронизации позволяет получить достаточно приемлемые результаты при простой стратегии сокрытия, такой как копирование блоков из предыдущего кадра.
Для дальнейшего улучшения техники сокрытия ошибок Видео Группа разработала дополнительный режим противодействия ошибкам, который дополнительно улучшает возможности декодера по локализации ошибок.
Этот подход использует разделение данных, сопряженных с движением и текстурой. Такая техника требует, чтобы был введен второй маркер ресинхронизации между данными движения и текстуры. Если информация текстуры потеряна, тогда для минимизации влияния ошибок используется информация перемещения. То есть, из-за ошибок текстурные данные отбрасываются, в то время данные о движении служат для компенсации перемещения как ранее декодированной VOP.
1.2. Состав медийных объектов
На Рисунок 1 объясняется способ описание аудио-визуальных сцен в MPEG-4, состоящих из отдельных объектов.
1. Совместимость с MIME
Механизмы, описанные в данном разделе являются открытыми для дальнейшего расширения. Не предполагается, что все реализации будут поддерживать все существующие типы среды. Для того чтобы обеспечить наибольшую область применимости полезно определить концепцию "MIME-совместимости", которая позволит обмениваться сообщениями, содержащими данные в формате, отличном от US-ASCII.
Почтовый агент пользователя, совместимый с MIME должен:
(1) | Всегда генерировать поле заголовка "MIME-Version: 1.0" в любом формируемом сообщении. |
(2) | Распознавать поле заголовка Content-Transfer-Encoding и декодировать все получаемые данные, кодированные в формате закавыченных последовательностей печатных символов или в base64. Должна идентифицироваться также форма преобразования (7-бит, 8-бит или двоичная). Любые не 7-битовые данные, посланные без кодирования, должны быть соответствующим образом помечены в поле content-transfer-encoding как 8-битовые или двоичные в зависимости от реального формата. Если транспортная система не поддерживает 8-битовый или двоичный формат (как, например, SMTP [RFC-821]), отправитель должен выполнить кодирование и пометить данные, как закодированные в формате base64 или закавыченных последовательностей печатных символов. |
(3) | Должен обрабатывать любые нераспознанные транспортные кодирования как тип содержимого "application/octet-stream", вне зависимости от того, распознан или нет действительный тип содержимого. |
(4) | Распознавать и интерпретировать поле заголовка Content-Type, и избегать отображения исходных данных со значением поля Content-Type, отличным от text. Реализации должны быть способны посылать, по крайней мере, сообщения text/plain, с символьным набором, специфицированным с помощью параметра charset, если это не US-ASCII. |
(5) | Игнорировать любые параметры типа содержимого с не распознанными именами. |
(6) | Работать с ниже приведенными значениями типов среды. |
Текст:
- | Распознавать и отображать "текст" почтового сообщения с символьным набором "US-ASCII." |
- | Распознавать другие символьные наборы, по крайней мере, на таком уровне, чтобы информировать пользователя о том, какой символьный набор использован. |
- | Распознавать символьные наборы "ISO-8859-*" на таком уровне, чтобы быть способным отобразить те символы, которые являются общими для ISO-8859-* и US-ASCII, то есть все символы с кодами в диапазоне 1-127. |
- | Для нераспознанных субтипов в рамках известного символьного набора показать или предложить показать версию исходных данных после преобразования содержимого из канонической формы в локальную. |
- | Обрабатывать материал с неизвестным символьным набором так, как если бы это был "application/octet-stream". |
- | На минимальном уровне предоставить возможность обрабатывать любой не узнанный субтип, как если бы он был "application/octet-stream". |
- | Предложить возможность удаления кодирования base64 или закавыченных последовательностей печатных символов, определенных в данном документе, если они были применены, и положить результат в файл пользователя. |
- | Распознается составной субтип. Отображает всю информацию на уровне сообщения и на уровне заголовка тела, а затем отображает или предлагает отобразить каждую из составляющих частей индивидуально. |
- | Распознается cубтип "alternative", и исключается отображение лишних частей сообщения multipart/alternative. |
- | Распознается субтип "multipart/digest", используя формат "message/RFC-822" а не "text/plain" в качестве типа среды по умолчанию для частей тела внутри объектов "multipart/digest". |
- | Любые не узнанные субтипы обрабатываются, как если бы они были типа "mixed". |
- | Распознаются и отображаются, по крайней мере, инкапсулированные данные сообщения RFC-822 (message/RFC-822) таким образом, чтобы сохранить любую рекурсивную структуру, то есть, отображая или предлагая отобразить инкапсулированные данные с учетом типа среды. |
- | Любые не распознанные субтипы обрабатывается как если бы они имели тип "application/octet-stream". |
(7) | При встрече нераспознанного поля Content-Type, программная реализация должна воспринимать ее как если бы она имела тип "application/octet-stream" без каких либо параметров субаргументов. Как обрабатывать эти данные зависит исключительно от конкретной реализации, но желательны опции, предлагающие пользователю после декодирования транспортного формата записать данные в файл или предложить пользователю ввести имя файла, который преобразует содержимое в приемлемый формат. |
(8) | Нужны адаптирующиеся агенты пользователя, если они предоставляют нестандартную поддержку для сообщений, не следующих протоколу MIME, и использующих символьный набор отличный от US-ASCII. Адаптирующиеся агенты пользователя не должны посылать сообщения, которые не следуют протоколу MIME и в то же время содержат текст отличный от US-ASCII. В частности, использование текста не US-ASCII в почтовом сообщении без поля MIME-Version категорически не рекомендуется, так как это уменьшает коммуникационные возможности. Адаптирующиеся агенты пользователя должны содержать корректные метки MIME при посылке чего-либо отличного от чистого текста с символьным набором US-ASCII. Кроме того, агенты пользователя, не поддерживающие MIME, должны модифицироваться, если это возможно, чтобы включить соответствующую информацию заголовка MIME в отправляемое сообщение, даже если ничего более из протокола MIME не поддерживается. Эта модификация произведет малое, если вообще какое-либо влияние на получателей, не поддерживающих MIME, но поможет MIME корректно отобразить текст сообщения. |
(9) | Адаптирующиеся агенты пользователя должны гарантировать, что любая строка печатных US-ASCII-символов (без WS) в пределах "*text" или "*ctext", которая начинается с "=?" и завершается "?=", является корректным кодировочным словом. Слово "начинается" здесь означает - в начале поля тела или сразу после LWS, а "завершается" означает - в конце поля-тела или сразу перед LWS. Кроме того любое "слово" в пределах "фразы", которое начинается с "=?" и завершается "?=", должно быть корректным кодировочным словом. |
(10) | Адаптирующиеся агенты пользователя должны быть способны отделит кодировочные слова от "text", "ctext" или "word", в соответствии с правилами секции 4, где бы они не встретились в заголовках сообщения. Они должны поддерживать как "B"- так и "Q"-кодирование для любого поддерживаемого символьного набора. Программа должна быть способна отобразить не кодированный текст, если символьным набором является "US-ASCII". Для символьных наборов ISO-8859-*, программа, читающая почтовые сообщения должна быть способна, по крайней мере, отобразить символы, которые входят также и в набор US-ASCII. Агент пользователя, который отвечает данным условиям, считается адаптированным к MIME. |
10.13 Список кодов и откликов на почтовые команды и сообщения
Код | Назначение |
211 | Сообщение о состоянии системы или справочный отклик (help). |
214 | Help message - сообщение для сведения. [Информация о том, как использовать приемник или значение конкретной нестандартной команды; этот отклик полезен только для пользователей-людей]. |
220 | <domain> Service ready - сервер готов к обслуживанию. |
221 | <domain> Service closing transmission channel - сервер закрывает канал; |
250 | Requested mail action okay, completed - процедура успешно завершена; |
251 | User not local; will forward to <forward-path> - адресат не местный, сообщение ему будет переадресовано. |
354 | Start mail input; end with <CRLF>.<CRLF> - начало ввода сообщения, завершение символьной последовательностью <CRLF>.<CRLF>. |
421 | <domain> Service not available, closing transmission channel - сервер не доступен, процедура прерывается. [Это может быть ответом на любую команду, если сервер знает, что он должен прервать обслуживание] |
450 | Requested mail action not taken: mailbox unavailable - запрошенная процедура не выполнена [Напр., из-за отсутствия доступа к почтовому ящику]. |
451 | Requested action aborted: error in processing – выполнение процедуры прервано из-за ошибки. |
452 | Requested action not taken: insufficient system storage - операция не выполнена из-за недостатка системной памяти. |
500 | Syntax error, команда не узнана. [Среди прочего, это может указывать на то, что командная строка имеет слишком большую длину]. |
501 | Syntax error in parameters or arguments – синтаксическая ошибка в параметрах или аргументах. |
502 | Command not implemented - нелегальная команда. |
503 | Bad sequence of commands - неудачная последовательность команд. |
504 | Command parameter not implemented - ошибка в параметрах команды. |
550 | Requested action not taken: mailbox unavailable - Запрошенная операция не выполнена [Напр., почтовый ящик не найден или доступ к нему невозможен]. |
551 | User not local; please try <forward-path> - адресат не местный, рекомендуется переадресовать сообщение по адресу <forward-path>. |
552 | Requested mail action aborted: exceeded storage allocation - операция прервана из-за превышения лимитов памяти (слишком много адресатов или слишком длинное сообщение). |
553 | Requested action not taken: mailbox name not allowed - операция не выполнена [Например, ошибка в записи адреса почтового ящика]. |
554 | Transaction failed - процедура не выполнена. |
10.20 Справочные данные по математике
Прекрасна благодушная язвительность, С которой в завихрениях истории Хохочет бесноватая действительность Над мудрым разумением теории | ||
И. Губерман |
Приводимые в данном разделе определения вляются "шпаргалкой" на случай, когда вы знаете предмет, но что-то забыли. Для первичного изучения математических основ рекомендую обратиться к серьезным монографиям и учебникам.
Условная вероятность.
В теории вероятностей характеристикой связи событий А и B служит условная вероятность P(А|B) события А при условии B, определяемая как P(А|B) =
,Если событие B ведет к обязательному осуществлению А: b
, то P(A|B)=1, если же наступление B исключает возможность события А: A*B=0, то P(A|B)=0. Если событие А представляет собой объединение непересекающихся событий A1, A2,…: A = , то P(A|B) = .Если имеется полная система несовместимых событий B =B1, B2,… т.е. такая система непересекающихся событий, одно из которых обязательно осуществляется, то вероятность события A (P(A)) выражается через условные вероятности P(A|B) следующим образом:
Множества.
Множество – это совокупность некоторых элементов. Если элемент х входит в множество А, это записывается как x О A. Соотношения A1 Н A2 или A2 К A1 означает, что A1 содержится во множестве A2 (каждый элемент х множества A1 входит в множество A2; A1 является подмножеством A2).
Суммой или объединением множеств А1 и А2 называется множество, обозначаемое A1 И A2, которое состоит из всех точек х, входящих хотя бы в одно из множеств A1 или A2.
Пересечением или произведением множеств А1 и А2 называется множество, обозначаемое A1З A2, A1*A2 или A1A2, которое состоит из всех точек х, одновременно входящих и в A1 и в A2; пересечение
произвольного числа множеств Аa состоит из всех точек х, которые одновременно входят во все множества Аa.Пустые множества обозначаются 0.
Множества, дополнительные к открытым множествам топологического пространства Х, называются замкнутыми.
Нормированное пространство Х называется гильбертовым, если определена числовая функция двух переменных х1 и х2, обозначаемая (x1,x2) и называемая скалярным произведением, обладающим следующими свойствами:
(x,x)і 0;
(x,x)=0 тогда и только тогда, когда х=0;
(l 1x1+l2
x2, x) = l 1(x1,x) + l 2(x2,x);
(x, l 1x1+l2
x2) = l1(x,x1) + l 2(x,x2)
при любых l1, l2 и x1, x2ОX. Норма ||x|| элемента гильбертова пространства Х определяется как ||x||=
.Счетно-гильбертово пространство Х называется ядерным, если для любого р найдется такое q и такой ядерный оператор А в гильбертовом пространстве Х со скалярным произведением (х1,x2)=(х1,х2)q, что (х1,x2)p=(Ax1,x2)q.
Действительное число M является верхней границей или нижней границей множества Sy действительных чисел y, если для всех y О Sy соответственно y Ј M или yі M. Множество действительных или комплексных чисел ограничено (имеет абсолютную границу), если верхнюю границу имеет множество абсолютных величин этих чисел; в противном случае множество не ограничено. Каждое непустое множество Sy действительных чисел y, имеющее верхнюю границу, имеет точную верхнюю границу (наименьшую верхнюю границу) sup y, а каждое непустое множество действительных чисел y, имеющее нижнюю границу, имеет точную нижнюю границу (наибольшую нижнюю границу) inf y. Если множество Sy конечно, то его точная верхняя граница sup y необходимо равна наибольшему значению (максимуму) max y, фактически принимаемому числом y в Sy, а точная нижняя граница inf y равна минимуму min y.
Множество называется открытым, если оно состоит только из внутренних точек. Точка P множества называется внутренней для множества S, если P имеет окрестность, целиком содержащуюся в S.
Компакт. Система множеств G называется центрированной, если пересечение конечного числа любых множеств из G не пусто. Замкнутое множество A Н X называется компактом, если всякая центрированная система G его замкнутых подмножеств F имеет непустое пересечение:
Множество А называется компактным в Х, если его замыкание F=[A] является компактом.Гауссовы случайные процессы.
Действительная случайная величина x называется гауссовой, если ее характеристическая функция j =j (u) имеет вид
;Марковские случайные процессы.
Случайный процесс x =x(t) на множестве T действительной прямой в фазовом пространстве (E,B) называется марковским, если условные вероятности P(A|U(-Ґ,s) событий AО U(t,Ґ ) относительно s-алгебры U(-Ґ,s) таковы, что при s Јt с вероятностью 1
(-Ґ,t1) и A2О U(t1, Ґ) и при любом t О T t1 ЈtЈ t2 с вероятностью 1
P(A1A2|x (t)) = P(A1|x (t)) P(A2|x(t)).
Цепи Маркова. Пусть x (t) - состояние системы в момент времени t, и пусть соблюдается следующая закономерность: если в данный момент времени s система находится в фазовом состоянии i, то в последующий момент времени t система будет находиться в состоянии j с некоторой вероятностью pij(s,t) независимо от поведения системы до указанного момента s. Описывающий поведение системы процесс x (t) называется цепью Маркова. Вероятности pij(s,t) = p{x (t)=j|x (s)=i} (i,j = 1, 2, …) называются переходными вероятностями марковской цепи x (t).
Марковская цепь x (t) называется однородной, если переходные вероятности pij(s,t) зависят лишь от разности t-s: pij(s,t) = pij(s-t) (i,j=1,2,…)
Финальные вероятности. Пусть состояния однородной марковской цепи x (t) образует один замкнутый положительный непериодический класс. Тогда для любого состояния j существует предел
(j=1, 2,…), один и тот же при всех исходных состояниях i=1,2,…. Предельные значения P1, P2,… представляют собой распределение вероятностей: pj есть финальная вероятность находиться в состоянии j; при этомPj=
(j=1,2,...),где Qj – среднее время возвращения в состояние j в дискретные моменты t = 0, 1, 2, … .
Коэффициент эргодичности. Пусть x =x (t) – случайный марковский процесс в фазовом пространстве (E,B) с переходной функцией P(s,x,t,B). С вероятностью 1 имеет место равенство
b
(s,t) =
|P(A| U(-?, s))- P(A| =
Величина k(s,t) = 1 -
называется коэффициентом эргодичности марковского процесса x =x (t).
Переходная функция. Функция P(s,x,t,B) переменных s, tО T, s Ј t и xО E, bО b называется переходной функцией марковского случайного процесса x =x (t) на множестве T в фазовом пространстве (E,B), если эта функция при фиксированных s, tО T и xО E представляет собой распределение вероятностей на s
-алгебре b и при фиксированных s, tО T и BО b является измеримой функцией от x О E.
Стационарные случайные процессы. Стационарный действительный или комплексный случайный процесс x =x (t), рассматриваемый как функция параметра t со значениями в гильбертовом пространстве L2(W) всех действительных или комплексных случайных величин h =h (w), M|h |2<Ґ (со скалярным произведением
(h 1, h2)= M h1
h2),
может быть представлен в виде
Белый шум. Простейшим по структуре стационарным процессом с дискретным временем является процесс z =z (t) с некоррелированными значениями:
Mz(t)=0, M|z(t)|2=1,
Mz(t1)
при t1 ? t2В случае непрерывного времени t аналогом такого процесса является так называемый “белый шум” – обобщенный стационарный процесс z = б u, z с вида
(параметр u=u(t) есть бесконечно дифференцируемая функция), где стохастическая мера z = z (d ) такова, что
Mz (D )=0, M|z (D )|2
=t-s при D =(s,t), Mz (D1) z (D2)=0 для любых непересекающихся D1 и D2.
Стационарный процесс x= x(t), Mx(t)=0, называется линейно-регулярным, если
где H(s,t) – замкнутая линейная оболочка в пространстве L2(W) значений x(u), s Ј u Ј t. Стационарный процесс x =x(t) со спектральной мерой F является линейно-регулярным тогда и только тогда, когда F=F( D) абсолютно непрерывна:
F(D) =
(для дискретного t)
(для непрерывного t)
Стационарный процесс x =x(t) линейно-регулярен тогда и только тогда, когда он получается некоторым физически осуществимым линейным преобразованием из процесса z = z(t) с некоррелированными значениями – в случае дискретного t:
x(t) =
и из процесса z =б u, z с “белого шума” – в случае непрерывного t:
x(t) =
Регулярность. Реальные стационарные процессы часто возникают в результате некоторого случайного стационарного возмущения Z = z (t) типа “белого шума”. Процесс z = z(t) подвергается некоторому линейному преобразованию и превращается в стационарный процесс x =x(t). Спектральная плотность f= f(l) такого процесса в диапазоне -p Ј l Ј p для целочисленного времени и -Ґ <l <Ґ для непрерывного времени t не может обращаться тождественно в нуль ни на каком интервале: в противном случае стационарный процесс x (t) будет сингулярным, что означает возможность его восстановления лишь на полуоси -Ґ ,t0. Процессы, спектр которых практически сосредоточен в полосе частот –W< l <W, не обладают свойствами сингулярных процессов. С энергетической точки зрения эти процессы имеют ограниченный спектр. Составляющие их гармонические колебания вида Ф(dl )eilt с частотами вне интервала (-W,W) имеют весьма малые энергии, но они существенно влияют на линейный прогноз значений x (t+t) на основе x (s) на временной полуоси sЈt.
Линейные устройства, используемые при решении конкретных задач, должны иметь вполне определенную постоянную времени T (определяет длительность переходных процессов). Это означает, что весовая функция h=h(t) рассматриваемого линейного устройства, связанная с соответствующей передаточной функцией Y =Y(p) равенством
был по возможности близок к входному полезному сигналу h = h(t), так что в стационарном режиме работы
Линейное устройство, отвечающее поставленным требованиям, должно иметь такую передаточную функцию Y=Y(p), чтобы соответствующая спектральная характеристика
являлась решением интегрального уравнения
Где
- спектральная плотность входного процесса x (t), а Bh h(t) – корреляционная функция полезного сигнала h (t).
Закон больших чисел. Пусть x1,…, xn – независимые случайные величины, имеющие одно и то же распределение вероятностей, в частности одни и те же математические ожидания a = M
xk и дисперсии
s2=Dxk, k=1,…,n. Каковы бы ни были e >0 и d >0, при достаточно большом n арифметическое среднее
с вероятностью, не меньшей 1-d, будет отличаться от математического ожидания a лишь не более чем на
Распределение Эрланга
Рассмотрим систему, которая способна обслуживать m запросов одновременно. Предположим, что имеется m линий и очередной запрос поступает на одну из них, если хотя бы одна из них свободна. В противном случае поступивший запрос будет отвергнут. Поток запросов считается пуассоновским с параметром l0, а время обслуживания запроса (в каждом из каналов) распределено по показательному закону с параметром l, причем запросы обслуживаются независимо друг от друга. Рассмотрим состояния E0, E1,…,Em, где Ek означает, что занято k линий. В частности E0 означает, что система свободна, а Em – система полностью занята. Переход из одного состояния в другое представляет собой марковский процесс, для которого плотности перехода можно описать как:
При t ® Ґ переходные вероятности pij(t) экспоненциально стремятся к своим окончательным значениям Pj, j=0,…,m. Окончательные вероятности Pj могут быть найдены из системы:
-l0P0+lP1=0
l0Pk-1 – (l0+kl)Pk + (k+1)lPk+1 =0 (1Ј k<m)
l0pm-1+ml Pm=0
решение которой имеет вид:
Эти выражения для вероятностей называются формулами (распределением) Эрланга.
Рисунок 20. Средства для описания концептуальных аспектов
Кроме семантического описания индивидуальных привязок в аудио-визуальном материале, семантические DS допускают также описание абстракций. Абстракция относится к процессу получения описания из специфической привязки к аудио-визуальному материалу и обобщению его с помощью нескольких привязок к этому материалу или к набору специальных описаний. Рассматриваются два типа абстракции, называемых медиа-абстракция и стандартная абстракция.
Медиа-абстракция представляет собой описание, которое отделено от конкретных образцов аудио-визуального материала, и может описывать все варианты и образцы аудио-визуального материала, которые достаточно схожи между собой (подобие зависит от приложения и от деталей описания). Типичным примером может служить новость, которая широковещательно передается по разным каналам.
Стандартная абстракция является обобщением медиа-абстракции для описания общего класса семантических сущностей или описаний. Вообще, стандартная абстракция получается путем замещения конкретных объектов, событий или других семантических сущностей классами. Например, если "Ваня играет на пианино" заменяется на "человек играет на пианино", описание становится стандартной абстракцией. Стандартные абстракции могут быть рекурсивными, то есть определять абстракцию абстракций. Обычно стандартная абстракция предназначена для повторного использования или ориентирована на применение в качестве ссылки.
Простой пример описания концептуальных аспектов показан на Рисунок 21. Описываемый мир включает в себя в данном случае Ваню Иванова играющего на фортепиано со своим учителем. Событие характеризуется семантическим описанием времени: "19:00 24-го апреля 2002", и семантикой места: "Консерватория". Описание включает одно событие: игра и четыре объекта: фортепьяно, Ваня Иванов, его учитель и абстрактное понятие музыканта. Последние три объекта принадлежат к классу агент.
9. Ссылки
[RFC-822] |
Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC-822, UDEL, August 1982. |
[RFC-2049] |
Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. |
[RFC-2045] |
Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC-2045, November 1996. |
[RFC-2046] |
Borenstein N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. |
[RFC-2048] |
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. |
IV. Процедуры регистрации
Какое счастье, что вокруг Живут привольно и просторно Слова и запах, цвет и звук, Фактура, линия и форма |
|
И. Губерман |
10.3 Стандартные мультикастинг-адреса Интернет
Адрес | Зона действия | Нормативный документ |
224.0.0.0 | Базовый адрес мультикастинга (зарезервировано) | RFC-1112 |
224.0.0.1 | Все системы этой субсети | RFC-1112 |
224.0.0.2 | Все маршрутизаторы этой субсети | |
224.0.0.3 | Не стандартизовано | |
224.0.0.4 | DVMRP маршрутизаторы | RFC-1075 |
224.0.0.5 | Все маршрутизаторы OSPFIGP | RFC-1583 |
224.0.0.6 | Заданные маршрутизаторы OSPFIGP | RFC-1583 |
224.0.0.7 | Маршрутизаторы ST | RFC-1190 |
224.0.0.8 | ЭВМ ST | RFC-1190 |
224.0.0.9 | Маршрутизаторы RIP2 | |
224.0.0.10 | Маршрутизаторы IGRP | |
224.0.0.11 | Mobile-Agents | |
224.0.0.12-224.0.0.255 | Не стандартизовано | |
224.0.1.0 | Группа менеджеров VMTP | RFC-1045 |
224.0.1.1 | Протокол сетевого времени | RFC-1119 |
224.0.1.2 | SGI-Dogfight | |
224.0.1.3 | Rwhod | |
224.0.1.4 | VNP | |
224.0.1.5 | Artificial Horizons - Aviator | |
224.0.1.6 | Сервер имен (NSS) | |
224.0.1.7 | AUDIONEWS - мультикастинг аудио-новостей | |
224.0.1.8 | SUN NIS + Информационная служба | |
224.0.1.9 | Мультикастинг транспортный протокол (MTP) | |
224.0.1.10 | IETF-1-LOW-AUDIO | |
224.0.1.11 | IETF-1-AUDIO | |
224.0.1.12 | IETF-1-VIDEO | |
224.0.1.13 | IETF-2-LOW-AUDIO | |
224.0.1.14 | IETF-2-AUDIO | |
224.0.1.15 | IETF-2-VIDEO | |
224.0.1.16 | MUSIC-SERVICE | |
224.0.1.17 | Телеметрия SEANET | |
224.0.1.18 | SEANET-IMAGE | |
224.0.1.19 | MLOADD | |
224.0.1.20 | Любой частный эксперимент | |
224.0.1.21 | DVMRP на MOSPF | |
224.0.1.22 | SVRLOC | |
224.0.1.23 | XINGTV | |
224.0.1.24 | microsoft-ds | |
224.0.1.25 | nbc-pro | |
224.0.1.26 | P>nbc-pfn | |
224.0.1.27-224.0.1.255 | Не стандартизовано | |
224.0.2.1 | "rwho" Group(BSD) (неофициально) | |
224.0.2.2 | SUN RPC PMAPPROC_CALLIT | |
224.0.3.000-224.0.3.255 | RFE Generic Service | |
224.0.4.000-224.0.4.255 | RFE Individual Conferences | |
224.0.5.000-224.0.5.127 | Группы CDPD | |
224.0.5.128-224.0.5.255 | Не стандартизовано | |
224.0.6.000-224.0.6.127 | Проект Cornell ISIS | |
224.0.6.128-224.0.6.255 | Не стандартизовано | |
224.1.0.0-224.1.255.255 | ST Multicast Groups | RFC-1190 |
224.2.0.0-224.2.255.255 | Multimedia Conference Calls | |
224.252.0.0-224.255.255.255 | DIS transient groups | |
232.0.0.0-232.255.255.255 | VMTP transient groups | RFC-1045 |
Рисунок 4.4.13.1.1 Структура идентификаторов переменных в MIB
В приведенной ниже таблице охарактеризованы четыре простые переменные, идентификаторы которых помещены в нижней части Рисунок 4.4.13.1.1. Все эти переменные допускают только чтение.
Имя переменной
Тип данных
Описание
Код
udpInDatagrams
counter
Число UDP-дейтограмм, присланных процессам пользователя.
1
udpNoPorts
counter
Число полученных UDP-дейтограмм, для которых отсутствует прикладной процесс в порте назначения.
2
udpInErrors
counter
Число не доставленных UDP-дейтограмм по причинам, отличающимся от отсутствия процесса со стороны порта назначения (напр., ошибка контрольной суммы).
3
udpOutDatagrams
counter
Число посланных UDP-дейтограмм.
4
udpTable
counter
Рисунок 4.1.8.1.3. Структура кадров в GSM
Каждый временной домен (TDM) содержит 148-битовый кадр данных, начинающийся и завершающийся последовательностью из трех нулей. Кадр имеет два 57-битовых поля данных, каждое из которых имеет специальный бит, который указывает на то, что лежит в кадре - голос или данные. Между информационными полями размещается поле синхронизации (Sync). Хотя информационный кадр имеет длительность 547 мксек, передатчику позволено передавать его лишь раз в 4615 мксек, так остальное время зарезервировано для передачи другими станциями. Если исключить накладные накладные расходы каждому соединению выделена полоса (без учета сжатия данных) 9600 кбит/с.
Восемь информационных кадров образуют TDM-кадр, а 26 TDM-кадров объединяются в 128-микросекундный мультифрейм. Как видно из рисунка 4.1.8.1.2 позиция 12 в мультифрейме занята для целей управления, а 25-я зарезервирована для будущих применений. Существует также стандарт на 51-позиционный мультифрейм, содержащий больше управляющих вставок. Управляющий канал используется для регистрации, актуализации положения и формирования соединения. Каждая стационарная станция поддерживает базу данных, где хранится информация обо всех обслуживаемых в данный момент клиентах. Общий управляющий канал делится на три субканала. Первый служит для обслуживания вызовов (paging channel), второй (random access channel) реализует произвольный доступ в рамках системы ALOHA (устанавливаются параметры вызова). Третий субканал служит для предоставления доступа (access grant channel).
Алгоритмы обслуживания мобильной связи достаточно нетривиальны. Из рисунка 4.1.8.1.1 видно, что области перекрываются (иначе бы существовали "мертвые" зоны без связи). Существуют даже субобласти, накрываемые тремя MSC. По это причине процедура должна четко определить, с каким из MSC клиент должен быть связан, и при каких условиях его следует переключить на соседний MSC, не прерывая связи. Система должна также компенсировать падение сигнала, иногда достаточно резкое, чтобы обеспечить комфортную связь и безошибочную передачу информации. По этой причине частота ошибок (BER) в таких сетях составляет 10-3 (против 10-6 для обычных стационарных цифровых каналов связи). Следует иметь в виду, что в условиях города сигнал падает пропорционально не квадрату, а четвертой степени расстояния. На распространение радиоволн в городе влияют ориентация улиц (до 20 дБ), туннели (до 30 дБ) и листва деревьев в сельской местности (до 18 дБ).
GSM - система базирующаяся в основном на коммутации каналов. Применение модема на переносной ЭВМ позволяет подключиться к сети Интернет. Но здесь не все беспроблемно. Базовые станции временами теряют связь друг с другом (переключение с канала на канал), что может приводить к 300 миллисекундным потери данных. Как уже говорилось выше, здесь высока вероятность ошибок. Так, нажав клавишу "a", можно получить на экране букву "я". Да и расценка за минуту работы в Интернет здесь весьма высока. В связи с этим был разработан стандарт на цифровую систему коммутации пакетов CDPD (Cellular Digital Packet Data). Система работает поверх AMPS. Система обеспечивает информационную пропускную способность на уровне 9,6 кбит/с. CDPD довольно точно следует модели OSI. В CDPD определены три типа интерфейсов. Е-интерфейс (внешний по отношению CDPD-провайдеру) соединяют CDPD-область с определенной сетью. I-интерфейс (внутренний по отношению CDPD-провайдеру) соединяет CDPD-области друг с другом. A-интерфейс (эфирный) используется для связи базовой станции с мобильной ЭВМ. В функции этого интерфейса входит сжатие и шифрование данных, а также исправление ошибок. 274-битные блоки сжатой и зашифрованной информации вкладываются в 378-битовые блоки, предназначенные для коррекции ошибок согласно алгоритму Рида-Соломона. К каждому такому блоку добавляется семь 6-битовых флагов. Результирующие блоки имеют 420 бит и передаются в виде семи 60-битовых микроблоков. Эти микроблоки передаются к базовой станции со скоростью 19,2 кбит/с. Канал с аналогичным быстродействием создается для пересылки информации в противоположном направлении. При обмене применяется мультиплексирование с делением по времени. При этом временные домены имеют длительность 3,125 мсек (60 бит).
Когда мобильная ЭВМ хочет что-то передать, прослушивается канал базовой станции и проверяется флаг, сообщающий, свободен ли входной канал базовой станции. Если канал занят, ЭВМ вместо ожидания до очередного временного домена, пропуская псевдослучайное число временных доменов, после чего повторяет попытку. Если повторная попытка неудачна, время ожидания увеличивается примерно вдвое. Когда, наконец, ЭВМ обнаруживает, что канал свободен, она начинает пересылку своих микроблоков. Предусмотрена процедура, препятствующая попытке всех ЭВМ, готовых к передаче, захватить канал, как только он оказался свободным. Этот алгоритм называется DSMA (Digital Sense Multiple Access). Но, несмотря на применение DSMA, столкновение все же возможно, так как две или более ЭВМ могут воспользоваться одним и тем же временным доменом для начала передачи. Для выявления столкновений предусмотрен специальный флаг, который позволяет судить, корректно ли доставлен предыдущий микроблок. К сожалению это происходит не мгновенно а лишь спустя несколько микроблоков. При обнаружении ошибки передача прерывается. Следует иметь в виду, что информационный обмен имеет более низкий приоритет по отношению передачи голосовых данных. Предусмотрена возможность создания выделенных CDPD-каналов.
GSM использует довольно сложную комбинацию методик ALOHA, TDM и FDM. CDPD для передачи одиночных кадров не вполне согласуется с алгоритмом CSMA. Впрочем существует еще один метод формирования радио каналов - CDMA (Code Division Multiple Access).
Метод CDMA принципиально отличается от описанных выше, которые использовали для дультиплексирования доступа FDM, TDM или ALOHA. CDMA позволяет каждой станции осуществлять передачу во всем частотном диапазоне постоянно. Множественные передачи реализуются с привлечением теории кодирования. Здесь предполагается, что сигналы, совпадающие по времени складываются линейно. В CDMA каждый бит-тайм делится на m коротких интервалов, называемых чипами. Обычно используется 64 или 128 чипов на бит. Каждой станции присваивается уникальный m-битный код (chip sequence). Чтобы передать 1 бит станция посылает свой чип-код. Для простоты далее будем предполагать, что m=8. Для того чтобы послать нулевой бит, посылается дополнение чип-кода по модулю один. Никакие другие кодовые последовательности не разрешены. Например, пусть станции 1 поставлен в соответствие чип-код 01010101, тогда при посылке логической 1 она отправляет код 01010101, а при отправке логического нуля - 10101010. Если имеется канал с полосой 1 МГц и 100 станций с FDM, то каждая из них получит по 10 КГц (10 кбит/c при 1 бите на Гц). При CDMA каждая станция использует весь частотный диапазон, так что будет получена скорость передачи 1 мегачип в секунду. При менее 100 чипов на бит CDMA обеспечивает большую пропускную способность, чем FDM. Для упрощения введем двуполярную нотацию, где нулю соответствует -1, а единице +1. Тогда чип-код станции 1 получит вид -1 +1 -1 +1 -1 +1 -1 +1. Каждая из станций получает уникальный чип-код. Чип-коды можно представить в виде m-компонентных векторов. Чип-коды выбираются так, что все они попарно ортогональны (не любой уникальный чип-код пригоден, так, если станция 1 имеет чип-код 01010101, то станция 2 не может иметь чип-код 10101001, но чип-код 10100101 вполне допустим). Математически это можно выразить следующим образом:
,где Hi и Gi компоненты векторов чип-кодов H и G. Это равенство указывает, что число разных компонентов равно числу равных. Если G и H ортогональны, то и
=0. В то же время: [1]Когда сигналы от разных станций совпадают во времени и складываются, принимающая сторона легко может вычислить наличие соответствующей компоненты. Если компоненты суммарного сигнала Si, то компоненты Gi вычисляются с помощью произведения Si*H. Действительно, если:
Здесь первые два слагаемых равны нулю в силу ортогональности выбранных чип-кодов. Последнее же слагаемое равно 1 согласно [1]. Во всех этих рассуждениях предполагалось, что все станции работают синхронно и начинают передачу чип-кодов одновременно.
Для пояснения метода рассмотрим конкретный пример в выше предложенной нотации. присвоим станциям F, G, H, I ортогональные чип-коды:
F=01010101 > -1 +1 -1 +1 -1 +1 -1 +1
G=10100101 > +1 -1 +1 -1 -1 +1 -1 +1
H=10011001 > +1 -1 -1 +1 +1 -1 -1 +1
I=11111111 > +1 +1 +1 +1 +1 +1 +1 +1
Теперь рассмотрим четыре варианта наложений:
Только F > S1=[-1 +1 -1 +1 -1 +1 -1 +1]
F+I > S2=[0 +2 0 +2 0 +2 0 +2]
F+G+H > S3=[+1 -1 -1 +1 -1 +1 -3 +3]
Для выявления наличия компоненты G выполним операции "умножения" согласно описанным выше правилам.
S1*G =[-1 -1 -1 -1 +1 +1 +1 +1]/8=0 (G отсутствует)
S2*G =[0 -2 0 -2 - +2 0 +2]/8=0 (G отсутствует)
S3*G =[+1 +1 -1 -1 +1 +1 +3 +3]/8=1 (G имеется - передана логическая 1)
S4*G =[-1 -1 -3 -3 -1 -1 +1 +1]/8=-1 (G имеется - передан логический 0)
Хотя теоретически здесь все прекрасно, наложение слишком большого числа чип-кодов может создать проблемы и, в конечном итоге, привести к ошибкам.
Идеальная мобильная система связи представляется в виде телефонной трубки, которой человек пользуется дома, в автомобиле, в отпуске или командировке. При этом телефонный номер не меняется, где бы вы не находились. Такая система разрабатывается в настоящее время и называется PCS (Personal Communication Services) в США. В остальном мире эта система имеет имя PCN (Personal Communications Network). PCS использует технику сотовой телефонной сети. Но здесь размер ячейки лежит в пределах 50-100 м (против 20 км для AMPS). Это позволяет работать с малой выходной мощностью порядка 0,25 Вт и понизить вес аппарата. При этом для покрытия той же области требуется в 40000 раз больше ячеек и, следовательно, такая система будет значительно дороже даже с учетом более низкой цены одной ячейки. Некоторые телефонные компании осознали, что старомодные телеграфные столбы являются идеальным местом для размещения базовых станций новой системы (провода уже имеются!). Для системы PCS зарегервирован диапазон частот 1,7-2,3 ГГц.
9.9. Структура средств для представления натурального видео
Алгоритмы кодирования изображение MPEG-4 и видео предоставляют эффективное представление визуальных объектов произвольной формы, а также поддержку функций, базирующихся на содержимом. Они поддерживают большинство функций, уже предлагаемых в MPEG-1 и MPEG-2, включая эффективное сжатие стандартных последовательностей прямоугольных изображений при варьируемых уровнях входных форматов, частотах кадров, глубине пикселей, скоростях передачи и разных уровнях пространственной, временной и качественной масштабируемости.
Базовая качественная классификация по скоростям передачи и функциональности визуального стандарта MPEG-4 для естественных изображений и видео представлена на Рисунок 11.
10.2.5. Сжатие тишины CELP
Средство “сжатия тишины” уменьшает среднюю скорость передачи благодаря более низкому сжатию пауз (тишины). В кодировщике, детектор активности голоса используется для разделения областей с нормальной голосовой активностью и зон молчания или фонового шума. Во время нормальной голосовой активности используется кодирование CELP как в версии 1. В противном случае передается дескриптор SID (Silence Insertion Descriptor) при малой скорости передачи. Этот дескриптор SID активирует в декодере CNG (Comfort Noise Generator). Амплитуда и форма спектра этого шума специфицируются энергией и параметрами LPC как в обычном кадре CELP. Эти параметры являются опционной частью SID и таким образом могут модифицироваться.
Таблица адресной информации данного объекта.
ipRouteTable
Последовательность записей маршрутной таблицы
Запись в маршрутной таблице
IPAdEntAddr
IPaddress
IP-адрес для данного ряда
IPadentifindex
integer
Число интерфейсов.
IPadentnetmask
IPaddress
Маска субсети для данного IP-адреса;
IPAdEntBcastAddr
[0...1]
Значение младшего бита широковещательного адреса (обычно 1);
IPAdEntReasmMaxsize
[0...65535]
Размер наибольшей IP-дейтограммы, полученной интерфейсом, которая может быть собрана.
Помимо простых переменных объектами MIB могут быть таблицы. Для каждой таблицы имеется один или несколько индексов.
Таблица анимации лица FAT (Face Animation Table) в рамках FDP (загружаемые таблицы функционального соответствия между приходящими FAP и будущими контрольными точками сетки лица. Это дает кусочно-линейную карту входящих FAP для управления движениями лица. Например: FAP может приказать ‘open_jaw (500)’ (открыть челюсти) и таблица определит, что это означает в терминах перемещения характерных точек;
Интерполяционная методика для лица FIT (Face Interpolation Technique) в BIFS (загружаемое определение карты входящих FAP в общий набор FAP до их использования в характерных точках, которая вычисляется с использованием полиномиальных функций при получении интерполяционного графа лица). Это может использоваться для установления комплексных перекрестных связей FAP или интерполяции FAP, потерянных в потоке, с привлечением FAP, которые доступны для терминала.
Эти специфицированные типы узлов в BIFS эффективно предоставляют для моделей формирования лица встроенную калибровку модели, работающей в терминале или загружаемой стандартной модели, включающей форму, текстуру и цвет.
Таблица данных специфичных для соединения
tcpInErrs
counter
Полное число сегментов, полученных с ошибкой.
tcpOutRsts
counter
Полное число посланных сегментов с флагом rst=1.
tcpconntable. tcp-таблица связей
tcpconnstate
[1...12]
Состояние соединения: 1 - closed; 2 - listen; 3 - syn_sent; 4 - syn_rcvd; 5 - established, 6 - fin_wait_1; 7 - fin_wait_2; 8 - close_wait; 9 - last_ack; 10 - closing; 11 - time_wait;, 12 - delete TCB. Только последняя переменная может устанавливаться менеджером, немедленно прерывая связь.
tcpconnlocal
address
ipaddress
Местный IP-адрес. 0.0.0.0 означает, что приемник готов установить связь через любой из интерфейсов.
tcpconnlocal
port
[0...65535]
Местный номер порта.
tcpconnlocal
address
ipaddress
Удаленный ip-адрес.
tcpconnrem
port
[0...65535]
Удаленный номер порта.
Таблица 4.4.13.1.5. Переменные ICMP-группы (тип данных – counter)
Переменная icmp-группы |
Описание |
Код |
icmpInMsgs |
Полное число полученных ICMP-сообщений. |
1 |
icmpInErrors |
Число ICMP-сообщений, полученных с ошибками. |
2 |
icmpInDestUnreach |
Число ICMP-сообщений о недостижимости адресата. |
3 |
icmpintimeexcds |
Число ICMP-сообщений об истечении времени. |
4 |
icmpInParmProbs |
Число полученных ICMP-сообщений о проблемах с параметрами. |
5 |
icmpInSrcQuench |
Число ICMP-сообщений с требованием сократить или прервать посылку пакетов из-за перегрузки. |
6 |
icmpInRedirects |
Число ICMP-сообщений о переадресации. |
7 |
icmpInEchos |
Число полученных ICMP-запросов отклика. |
8 |
icmpInEchoReps |
Число полученных ICMP-эхо- откликов. |
9 |
icmpInTimestamps |
Число ICMP-запросов временных меток. |
10 |
icmpInTimestampReps |
Число ICMP-откликов временных меток. |
11 |
icmpInAddrMasks |
Число ICMP-запросов адресных масок. |
12 |
icmpInAddrMaskReps |
Число ICMP-откликов на запросы адресных масок. |
13 |
icmpOutMsgs |
Число отправленных ICMP- сообщений. |
14 |
icmpOutErrors |
Число не отправленных ICMP- сообщений из-за проблем в ICMP (напр. нехватка буферов). |
15 |
icmpOutDestUnreachs |
Число ICMP-сообщений о недоступности адресата. |
16 |
icmpOutTimesExcds |
Число посланных ICMP-сообщений об истечении времени. |
17 |
icmpOutParmProbs |
Число посланных ICMP-сообщений о проблемах с параметрами. |
18 |
icmpOutSrcQuench |
Число посланных ICMP-сообщений об уменьшении потока пакетов. |
19 |
icmpOutRedirects |
Число посланных ICMP-сообщений о переадресации. |
20 |
icmpOutEchos |
Число посланных ICMP-эхо-запросов. |
21 |
icmpOutEchoReps |
Число посланных ICMP-эхо-откликов. |
22 |
icmpOutTimestamps |
Число посланных ICMP-запросов временных меток. |
23 |
icmpOutTimestampReps |
Число посланных ICMP-откликов на запросы временных меток. |
24 |
icmpOutAddrMasks |
Число посланных ICMP-запросов адресных масок. |
25 |
Таблица 4.4.13.1.8. Функциональные группы RMON
Группа
Назначение
statistics
Таблица карты таких потоков связывает каждый поток с ChannelAssociationTag (канальной меткой), которая служит указателем для канала, через который идет поток. Определение ChannelAssociationTags для реального транспортного канала, а также управление сессией и каналами осуществляется DMIF-частью стандарта MPEG-4.
Во-вторых, входящие потоки должны быть соответствующим образом демультиплексированы, чтобы восстановить SL-потоки пакетов от нижележащих каналов (входящих в принимающий терминал). В интерактивных приложениях, соответствующий узел мультиплексирования переправляет данные в вышерасположенные каналы (исходящие из принимающего терминала).
Базовый термин ‘TransMux Layer’ используется, чтобы абстрагироваться от нижележащей функциональности – существующей или будущей, которая пригодна для транспортировки потоков данных MPEG-4. Заметим, что этот уровень не определен в контексте MPEG-4. Примерами могут служить транспортный поток MPEG-2, H.223, ATM AAL 2, IP/UDP. Предполагается, что слой TransMux предоставляет защиту и средства мультиплексирования, этот уровень обеспечивает определенный класс QoS. Средства безопасности включают в себя защиту от ошибок и детектирование ошибок, удобное для данной сети или устройств памяти.
В любом конкретном сценарии приложения используется один или более специфических TransMux. Каждый демультиплексор TransMux предоставляет доступ к каналам TransMux. Требования на информационный интерфейс доступа к каналу TransMux те же, что и для всех интерфейсов TransMux. Они включают необходимость надежного детектирования ошибок, доставки, если возможно, ошибочных данных с приемлемой индикацией ошибок и кадрирование поля данных, которое может включать потоки либо SL либо FlexMux. Эти требования реализованы в интерфейсе TransMux (системная часть стандарта MPEG-4). Адаптация потоков SL должна быть специфицирована для каждого стека протоколов.
Средство FlexMux специфицировано MPEG для того, чтобы опционно предоставить гибкий метод, имеющий малую избыточность и задержку для переукладки данных в тех случаях, когда ниже лежащие протоколы не поддерживают это. Средство FlexMux само по себе недостаточно устойчиво по отношению к ошибкам и может либо использоваться в каналах TransMux с высоким QoS, либо для объединения элементарных потоков, которые достаточно устойчивы к ошибкам. FlexMux требует надежного детектирования ошибок. Эти требования реализованы в информационных примитивах прикладного интерфейса DMIF, который определяет доступ к данным в индивидуальных транспортных каналах. Демультиплексор FlexMux выделяет SL-потоки из потоков FlexMux.
Таблица .1. Коды Base64
Код символа (6 бит) |
ASCII символ |
Код символа (6 бит) |
ASCII символ |
Код символа (6 бит) |
ASCII символ |
Код символа (6 бит) |
ASCII символ |
0 |
A |
10 |
Q |
20 |
g |
30 |
w |
1 |
B |
11 |
R |
21 |
h |
31 |
x |
2 |
C |
12 |
S |
22 |
i |
32 |
y |
3 |
D |
13 |
T |
23 |
j |
33 |
z |
4 |
E |
14 |
U |
24 |
k |
34 |
0 |
5 |
F |
15 |
V |
25 |
l |
35 |
1 |
6 |
G |
16 |
W |
26 |
m |
36 |
2 |
7 |
H |
17 |
X |
27 |
n |
37 |
3 |
8 |
I |
18 |
Y |
28 |
o |
38 |
4 |
9 |
J |
19 |
Z |
29 |
p |
39 |
5 |
A |
K |
1A |
a |
2A |
q |
3A |
6 |
B |
L |
1B |
b |
2B |
r |
3B |
7 |
C |
M |
1C |
c |
2C |
s |
3C |
8 |
D |
N |
1D |
d |
2D |
t |
3D |
9 |
E |
O |
1E |
e |
2E |
u |
3E |
+ |
F |
P |
1F |
f |
2F |
v |
3F |
/ |
Закодированный выходной поток должен иметь формат последовательности из одной или более строк длиной не более 76 символов каждая. Все разрывы строк или другие символы, не содержащиеся в таблице .1. должны игнорироваться декодирующим программным обеспечением. В данных, представленных в кодах base64, символы отличные от тех, что представлены в таблице .1., разрывы строк и другие пробелы обычно указывает на ошибку передачи, которая вызовет предупреждение или даже выбрасывание сообщения.
Если число бит в группе меньше 24, используется специальная обработка. Неполная битовая группа дополняется нулями справа до 24. Заполнение в конце информационной группы осуществляется с использованием символа "=". Так как последовательность кодов base64 представляет собой поток октетов, возможны следующие случаи:
последний блок кодируемых данных кратен 24 битам; здесь, завершающий выходной блок будет содержать в себе 4 символа и никакого заполнителя,
завершающий блок кодируемых данных содержит ровно 8 бит; здесь, оконечный выходной блок будет содержать два символа, за которыми будут следовать два символа заполнителя, или
последний блок кодируемой информации содержит ровно 16 бит; здесь, оконечный блок на выходе будет иметь три символа плюс один символ заполнителя "=".
Так как "=" используется для дополнения, его наличие указывает на то, что достигнут конец массива данных.
Такая уверенность не возможна, когда число переданных октетов кратно трем и нет ни одного символа "=". Любые символы, не входящие в алфавит base64-должны игнорироваться.
Следует позаботиться о том, чтобы использовались корректные октеты в качестве разделителей строк при работе с base64. В частности, разрывы строк должны быть преобразованы в последовательности CRLF до выполнения кодирования base64.
6. Поле заголовка Content-ID
При создании агента пользователя высокого уровня, может быть желательно, допустить одному телу ссылаться на другое. Тела могут быть помечены с помощью поля заголовка "Content-ID", которое синтаксически идентично полю "Message-ID":
id := "Content-ID" ":" msg-id
Подобно значениям Message-ID, значения Content-ID должны генерироваться уникальными.
Значение Content-ID может использоваться для идентификации MIME-объектов в нескольких контекстах, в частности для кэширования данных с доступом через механизм message/external-body. Хотя заголовок Content-ID является обычно опционным, его использование является обязательным в приложениях, которые генерируют данные опционного типа среды MIME "message/external-body". По этой причине каждый объект message/external-body должен иметь поле Content-ID, для того чтобы разрешить кэширование таких данных.
Таблица 4.5.10.3. Коды Base64
Код символа (6 бит) |
ASCII символ |
Код символа (6 бит) |
ASCII символ |
Код символа (6 бит) |
ASCII символ |
Код символа (6 бит) |
ASCII символ |
0 |
A |
10 |
Q |
20 |
g |
30 |
w |
1 |
B |
11 |
R |
21 |
h |
31 |
x |
2 |
C |
12 |
S |
22 |
i |
32 |
y |
3 |
D |
13 |
T |
23 |
j |
33 |
z |
4 |
E |
14 |
U |
24 |
k |
34 |
0 |
5 |
F |
15 |
V |
25 |
l |
35 |
1 |
6 |
G |
16 |
W |
26 |
m |
36 |
2 |
7 |
H |
17 |
X |
27 |
n |
37 |
3 |
8 |
I |
18 |
Y |
28 |
o |
38 |
4 |
9 |
J |
19 |
Z |
29 |
p |
39 |
5 |
A |
K |
1A |
a |
2A |
q |
3A |
6 |
B |
L |
1B |
b |
2B |
r |
3B |
7 |
C |
M |
1C |
c |
2C |
s |
3C |
8 |
D |
N |
1D |
d |
2D |
t |
3D |
9 |
E |
O |
1E |
e |
2E |
u |
3E |
+ |
F |
P |
1F |
f |
2F |
v |
3F |
/ |
Интересным дополнением к традиционной электронной почте является ее расширение MIME (Multipurpose Internet Mail Extensions, RFC-1521). MIME не требует каких-либо переделок в почтовых серверах, это расширение определяет пять новых полей-заголовков (расширение RFC-822):
MIME-Version: |
(версия MIME, сейчас 1.0) |
Content-Type: |
(тип содержимого, см. таблицу на Рисунок 4.5.10.4) |
Content-Transfer-Encoding: |
(кодирование содержимого) |
Content-ID: |
(идентификатор содержимого) |
Content-Description: |
(описание содержимого) |
Поле заголовка Content-Transfer-Encoding используется пять видов кодировки (третий вид полей в приведенном выше списке):
7-бит (NVT ASCII, по умолчанию);
Набор печатных символов (полезен, когда только небольшая часть символов использует 8-ой бит);
64-символьный набор (Base64 см. выше в таблице 4.5.10.3);
8-битный набор символов, включающий псевдографику, с использованием построчного представления;
Двоичная кодировка (8-битное представление без построчного представления).
Только первые три типа согласуются с требованиями RFC-821. MIME позволяет снять с электронной почты привычные ограничения и предоставляет возможность пересылать любую информацию. Техника приложений (Attachment) позволяет пересылать через электронную почту любые файлы без какого-либо специального преобразования, выполняемого пользователем. При этом необходимо только, чтобы и приемник и передатчик поддерживали это расширение электронной почты. В MIME предусмотрены следующие типы и субтипы содержимого почтового сообщения:
Таблица 4.4.13.1.7 Коды-префиксы производителей
Код префикса |
Название фирмы |
0 | Зарезервировано |
1 | Proteon |
2 | IBM |
3 | CMU |
4 | UNIX |
5 | ACC |
6 | TWG |
7 | Cayman |
8 | PSI |
9 | Cisco |
10 | NSC |
11 | HP |
12 | Epilogue |
13 | U of Tennessee |
14 | BBN |
15 | Xylogics, inc. |
16 | Unisys |
17 | Canstar |
18 | Wellfleet |
19 | TRW |
20 | MIT |
Группа локальных переменных IP checkpoint accounting (1.3.6.1.4.1.9.2.4.7.1) представляет собой таблицу, содержащую в каждом рекорде по четыре переменных (в скобках указан суффикс адреса MIBдля переменной):
ckactbyts [4] - число переданных байт,
ckactdst [2] - адрес места назначения,
ckactpkts [3] - число переданных пакетов
ckactsrc [1] - адрес отправителя
Маршрутизаторы Cisco поддерживают две базы данных: active accounting и checkpoint accounting. В первую заносятся текущие результаты измерения входящего и исходящего трафика. Эти результаты копируются в базу данных checkpoint accounting и, если там уже имеются предыдущие данные, они объединяются. Для очистки базы данных checkpointed database выдается команда clear IP accounting, а для базы checkpoint – clear IP accounting checkpoint (для использования этих команд необходимы системные привилегии). Объем памяти, выделяемой для этих баз данных задается командой IP accounting-threshold , по умолчанию максимальное число записей в базе данных равно 512.
Лучшим способом закрепить в памяти все вышесказанное является использование программы SNMPI (SNMP initiator) или ее аналога. Если в вашем распоряжении имеется ЭВМ, работающая под unix, например SUN, вы можете попутно узнать много полезного о вашей локальной сети. Ниже описан синтаксис обращения к SNMPI.
snmpi [-a agent] [-c community] [-f file] [-p portno] [-d] [-v] [-w]
SNMPI - крайне простая программа, используемая для тестирования SNMPD. Для того чтобы проверить, работает ли она, выдайте команду:
% SNMPI dump
Следует отметить, что в ответ на эту операцию будет произведена весьма объемная выдача.
Опция -a предлагает возможность ввести адрес SNMP-объекта - имя ЭВМ, IP-адрес или транспортный адрес.
По умолчанию это местная ЭВМ. Аналогично опция -p позволяет задать номер UDP-порта. По умолчанию это порт 161.
Опция -c позволяет задать групповой пароль (community) для snmp-запроса. По умолчанию - это public, т.е. свободный доступ.
Опция -f позволяет выбрать файл, содержащий откомпилированные описания mib-модулей. По умолчанию - это objects.defs.
Опция -w включает режим наблюдения, осуществляя выдачу на терминал всех служебных сообщений. Уход из программы по команде quit (q).
Если вы работаете на IBM/PC, и ваша машина подключена к локальной сети, получите допуск к одной из UNIX-машин в сети (если вы его не имели) и приступайте. Можно начать с обращения типа:
SNMPI -a 193.124.224.33 (адрес или символьное имя надо взять из вашей локальной сети)
Машина откликнется, отобразив на экране SNMPI>, это означает, что программа имеется и вы можете вводить любые команды.
Начать можно со знакомства с системными переменными системы (в дальнейшем курсивом выделены команды, введенные с клавиатуры):
SNMPI> get sysdescr.0
snmpi> sysdescr.0="GS software (gs3-k), version 9.1(4) [fc1], software copyright (c) 1986-1993 by cisco systems, inc. compiled thu 25-mar-93 09:49 by daveu"
snmpi> get sysobjectid.0
snmpi> sysobjectid.0=1.3.6.1.4.1.9.1.1
snmpi> get sysuptime.0
snmpi> sysuptime.0=14 days, 7 hours, 0 minutes, 15.27 seconds (123481527 timeticks)
snmpi> get sysservices.0
snmpi> sysservices.0=0x6
Код 0x06 (sysservices.0) представляет собой сумму кодов уровней модели iso, поддерживаемых системой. Для справок: 0x01 - физический уровень; 0x02 – связной уровень; 0x04 - Интернет; 0x08 - связь точка-точка; 0x40 - прикладной уровень.
Если вы хотите получить информацию о состоянии интерфейсов на одной из ЭВМ, подключенных к вашей локальной сети (команды вызова snmpi далее не повторяются; в ниже приведенных примерах в круглых скобках помещены комментарии автора), выдайте команды:
SNMPI> next iftabl (команда next в данном случае соответствует запросу get-next, здесь понятие "следующий" подразумевает порядок переменных в MIB)
snmpi> ifindex.1=1
snmpi> get ifdescr.1
snmpi> ifdescr.1="ethernet0"
snmpi> get iftype.1
snmpi> iftype.1=ethernet-csmacd(6)
snmpi> get ifmtu.1
snmpi> ifmtu.1=1500
snmpi> get ifspeed.1
snmpi> ifspeed.1=10000000 (10Мб/с ethernet)
snmpi> get ifphysaddress.1
snmpi> ifphysaddress.1=0x00:00:0c:02:3a:49 (физический адрес интерфейса)
snmpi> next ifdescr.1 iftype.1 ifmtu.1 ifspeed.1 ifphysaddress.1
snmpi> ifdescr.2="serial0"
iftype.2=proppointtopointserial(22)
ifmtu.2=1500
ifspeed.2=2048000 (2 Мбит/ c радиорелейный последовательный канал, спутниковый канал был бы охарактеризован точно также).
ifphysaddress.2=
В приведенном примере размеры пересылаемых блоков для Ethernet и радиорелейного последовательного канала идентичны и равны 1500. Помните, что SLIP-канал характеризуется как pointtopointserial, а не slip. Скорость обмена по SLIP-каналу не сообщается.
Теперь просмотрим некоторые UDP-переменные. Например:
SNMPI> next UDP
SNMPI> udpindatagrams.0=98931
SNMPI> next udpindatagrams.0 (обратите внимание на суффикс простой переменной)
SNMPI> udpnoports.0=60009
SNMPI> next udplocaladdress.0
SNMPI>udplocaladdress.193.124.137.14.7=193.124.137.14
(Идентификатор этого объекта - 1.3.6.1.2.1.7.5.1.1.193.124.137.14.7.)
SNMPI> next udplocalport
SNMPI> udplocalport.193.124.137.14.7=7
Если у вас возникла необходимость просмотреть таблицу, например, udptable, это
также можно сделать, используя snmpi:
SNMPI> next udptable
SNMPI> udplocaladdress.193.124.137.14.7=193.124.137.14
SNMPI> next udplocaladdress.193.124.137.14.7
SNMPI> udplocaladdress.193.124.224.33.67=193.124.224.33
SNMPI> next udplocaladdress.193.124.224.33.67
SNMPI> udplocaladdress.193.124.224.33.161=193.124.224.33
SNMPI> next udplocalport.193.124.224.33.67
SNMPI> udplocalport.193.124.224.33.161=161
Ниже показана методика выяснения алгоритма и параметров задания величины тайм-аута:
SNMPI> get tcprtoalgorithm.0 tcprtomin.0 tcprtomax.0 tcpmaxconn.0
SNMPI> tcprtoalgorithm.0=vanj(4) (vanj - алгоритм Ван Джакобсона для расчета времени тайм-аута)
tcprtomin.0=300 | (минимальное значение тайм-аута = 300 мс) |
tcprtomax.0=60000 | (максимальное - 60 сек) |
tcpmaxconn.0=-1 | (никаких ограничений на число соединений) |
atifindex.1.1.193.124.224.33= | 1 |
atifindex.1.1.193.124.224.35= | 1 |
atifindex.3.1.192.148.166.203= | 3 |
atifindex.3.1.192.148.166.205= | 3 |
atifindex.5.1.145.249.30.33= | 5 |
atifindex.5.1.192.148.166.98= | 5 |
atphysaddress.1.1.193.124.224.33= | 0x00:00:0c:02:3a:49 |
atphysaddress.1.1.193.124.224.35= | 0x08:00:20:12:1b:b1 |
atphysaddress.1.1.193.124.224.40= | 0x00:00:cd:f9:0d:e7 |
atphysaddress.1.1.193.124.224.50= | 0x00:00:0c:02:fb:c5 |
atnetaddress.1.1.193.124.224.33= | 193.124.224.33 |
atnetaddress.1.1.193.124.224.35= | 193.124.224.35 |
atnetaddress.1.1.193.124.224.40= | 193.124.224.40 |
atnetaddress.1.1.193.124.224.50= | 193.124.224.50 |
atnetaddress.1.1.193.124.224.60= | 193.124.224.60 |
snmpi> ipadentaddr.192.148.166.222= | 192.148.166.222 |
ipadentaddr.192.168.1.1= | 192.168.1.1 |
ipadentaddr.192.168.1.2= | 192.168.1.2 |
ipadentaddr.193.124.224.33= | 193.124.224.33 |
ipadentaddr.193.124.224.190= | 193.124.224.190 |
ipadentifindex.192.148.166.222= | 3 |
ipadentifindex.192.168.1.1= | 4 |
ipadentifindex.192.168.1.2= | 6 |
ipadentifindex.193.124.224.33= | 1 |
ipadentifindex.193.124.224.190= | 5 |
ipadentnetmask.192.148.166.222= | 255.255.255.224 |
ipadentnetmask.192.168.1.1= | 255.255.255.0 |
ipadentnetmask.192.168.1.2= | 255.255.255.0 |
ipadentnetmask.193.124.224.33= | 255.255.255.224 |
ipadentnetmask.193.124.224.190= | 255.255.255.224 |
ipadentbcastaddr.192.168.1.1= | 1 |
ipadentbcastaddr.192.168.1.2= | 1 |
ipadentbcastaddr.193.124.224.33= | 1 |
ipadentbcastaddr.193.124.224.190= | 1 |
ipadentreasmmaxsize.192.168.1.1= | 18024 |
ipadentreasmmaxsize.192.168.1.2= | 18024 |
ipadentreasmmaxsize.193.124.224.33= | 18024 |
ipadentreasmmaxsize.193.124.224.190= | 18024 |
Таблица 4.5.10.2. Команды, выполняемые почтовой программой
Команда |
Описание |
|
Сокращение |
Полное имя |
|
? |
- |
Отображение списка исполняемых команд |
! |
- |
Выполнение одной команды Shell |
+ |
- |
Отобразить следующее сообщение |
RETURN |
- |
Отобразить следующее сообщение |
- |
- |
Отобразить предшествующее сообщение |
число |
- |
Отобразить сообщение с номером "число". |
d |
delete |
Стереть текущее сообщение |
dp |
- |
Стереть текущее сообщение и отобразить следующее |
e |
edit |
Вызвать редактор для работы с сообщениями |
h |
headers |
Отобразить список заголовков сообщений |
l |
list |
Выдать список имен всех доступных команд |
m |
Послать сообщение по указанному адресу или адресам |
|
n |
- |
Отобразить следующее сообщение и распечатать его |
p |
Отобразить (отпечатать) сообщения |
|
pre |
preserve |
Сохранить сообщения в системном почтовом ящике |
q |
quit |
Завершить работу с почтой |
r |
replay |
Ответить отправителю и всем прочим получателям |
R |
Replay |
Ответить только отправителю |
s |
save |
Сохранить сообщения в указанном файле или в mbox, если имя файла не указано |
sh |
shell |
Временно уйти из почты и вернуться в shell |
t |
type |
Тоже что и print |
to |
top |
Отобразить несколько верхних строчек сообщения |
u |
undelete |
Восстановить ранее стертые сообщения |
v |
- |
Редактирование сообщения с помощью экранного редактора |
w |
write |
Тоже что и s, но без записи заголовка |
x |
exit |
Выйти из почты без спасения внесенных изменений |
z |
- |
Отобразить следующий набор заголовков |
z- |
- |
Отобразить предшествовавший набор заголовков сообщений |
Ключевое слово 8BITMIME говорит о том, что клиент может добавить ключевое слово BODY к команде MAIL FROM и определить тип символов, используемых в сообщении (ASCII или 8-битные). Ключевое слово XADR указывает на то, что любые ключевые слова, начинающиеся с X, относятся к местным модификациям SMTP. Документ RFC-1522 определяет способ, как можно включить не ASCII-символы в заголовок почтового сообщения. Например:
=?набор_символов ?кодировка ?закодированный_текст ?=
набор_символов - спецификация набора символов: us-ascii или ISO-8859-X, где X - одиночная цифра, например ISO-8859-1. Поле кодировка содержит один символ, характеризующий метод кодировки. В настоящее время описаны два метода:
1. Q - набор печатных символов; символы, коды которых имеют неравный нулю 8-ой бит, отображается тремя символами: знаком равенства (=), за которым следует два шестнадцатеричных числа (например =AD). Так пробел будет иметь кодировку =20.
2. B - 64-символьный набор (Base64, латинские буквы, 10 цифр, а также символы + и /). Набор кодов Base64 приведен в таблице:
Таблица, которая отслеживает около 20 статистических параметров сетевого трафика, включая общее число кадров и количество ошибок
history
Позволяет задать частоту и интервалы для измерений трафика
alarm
Позволяет установить порог и критерии, при которых агенты выдают сигнал тревоги
host
Таблица, содержащая все узлы сети, данные по которым приводятся в сетевой статистике
hostTopN
Позволяет создать упорядоченные списки, которые базируются на пиковых значениях трафика группы ЭВМ
matrix
Две таблицы статистики трафика между парами узлов. Одна таблица базируется на адресах узлов-отправителей, другая – на адресах узлов-получателей
filter
Позволяет определить конкретные характеристики кадров в канале. Например, можно выделить TCP-трафик.
packet capture
Работает совместно с группой filter. Позволяет специфицировать объем ресурса памяти, выделяемой для запоминания кадров, которые отвечают критериям filter.
event
Позволяет специфицировать набор параметров или условий, которые должен контролировать агент. Когда условия выполняются, информация о событии записывается в специальный журнал
<
Для того чтобы реализовать функционирование RMON-агента, сетевая карта должна быть способна работать в режиме 6 (promiscuous mode), когда воспринимаются все пакеты, следующие по кабельному сетевому сегменту.
Таблица 4.3.7.1. Основные протоколы модемов
Название |
Тип модуляции |
Назначение протокола |
V.21 |
FSK |
Дуплексный модем на 300 бит/с для телефонных сетей общего назначения, используется факс-аппаратами и факс-модемами |
V.22 |
DPSK |
Дуплексной модем для работы при скоростях 600/1200бит/с |
V.22bis |
QAM |
Дуплексной модем для работы при скоростях 1200/2400бит/с |
V.23 |
FSK |
Асинхронный модем на частоту 600/1200бит/с (сети videotex), несовместим с V.21, V.22 и V.22bis |
V.24 |
|
Стандарт на схемы сочленения DTE и DCE |
V.26 |
|
Модем для работы на выделенную линию на частотах 2400/1200бит/с |
V.27 |
|
Модем для работы на частотах 4800бод/с |
V.27bis |
|
Модем для работы на выделенную линию на частотах 2400/4800бит/с |
V.27ter |
DPSK |
Модем с набором телефонного номера на частоту 2400/4800бит/с (fax) |
V.29 |
QAM |
Модем на частоту 9600бит/с для 4-проводных выделенных линий (fax) |
V.32 |
QAM tcm |
Семейство 2-проводных модемов, работающих на частотах до 9600бит/с |
V.32bis |
TCM |
Модем, работающий на выделенную линию для частот 7200, 12000 и 14400бит/с |
V.33 |
TCM |
Модем на частоту 14.4кбит/с для выделенных линий |
V.34 |
|
Модем на частоту 28.8кбит/с, использован новый протокол установления связи |
V.34bis |
|
Модем на частоту 32 кбит/с |
V.35 |
|
Модем, работающий на выделенную линию с частотами до 9600бит/с |
V.42bis |
|
Стандарт для сжатия данных в модемах (4:1) |
Начиная с модемов V.32bis, стала использоваться динамическая регулировка скорости в ходе телекоммуникационной сессии в зависимости от состояния линии связи. Качество линии отслеживается по отношению сигнал/шум или по проценту блоков, переданных с ошибкой за определенный период времени.
Важным свойством модемов является возможность коррекции ошибок и сжатия информации. Ошибки корректируются путем повторной пересылки ошибочных блоков (ARQ - automatic repeat request). Ошибки контролируются с использованием CRC (cyclic redundancy check). Этим целям отвечает стандарт V.42, принятый еще в 1988 году, он включает в себя протокол LAPM (link access procedure for modems) и один из протоколов mnp (microcom networking protocol). В V.42 применен алгоритм сжатия информации Lempel-Ziv. При установлении связи между модемами определяется, какой из протоколов коррекции и сжатия они оба поддерживают. Если это V.42, то они сначала пытаются работать с использованием протокола LAPM. При неудаче (один из модемов не поддерживает V.42) используется протокол MNP. Перечисленные ниже алгоритмы коррекции ошибок и сжатия информации работают только для асинхронных модемов. Для синхронных модемов известен алгоритм сжатия SDS (synchronous data compression) фирмы motorola (коэффициент упаковки ~3.5, что для модемов V.34 может довести скорость обмена до 100кбит/с).
Ниже приведена таблица основных протоколов детектирования ошибок и сжатия информации, все протоколы mnp совместимы снизу вверх. При установлении связи между модемами используется наивысший протокол, поддерживаемый с обеих сторон канала.
Таблица 4.4.13.1.6. Переменные AT-группы (attable, преобразование адресов).
Переменные at-группы |
Тип данных |
Описание |
atEntry |
atIfIndex |
integer |
Число интерфейсов. |
1 |
atPhysAddress |
physaddress |
Физический адрес. Если эта переменная равна строке нулевой длины, физический адрес отсутствует. |
2 |
atNetAddress |
networkaddress |
IP-адрес. |
3 |
Каждый протокол (например IP) имеет свою таблицу преобразования адресов. Для IP это ipnettomediatable. Способ пропечатать эту таблицу с помощью программы SNMPI описан ниже.
MIB II содержит управляемые объекты, принадлежащие к группе snmp. SNMP-группа предоставляет информацию о SNMP-объектах, информационных потоках, о статистике ошибок:
Название объекта |
Описание |
Код |
snmpInPkts |
Число пакетов, полученных от слоя, расположенного ниже SNMP. |
1 |
snmpOutPkts |
Число пакетов доставленных от SNMP к нижележащему слою. |
2 |
snmpInBadVersions |
Индицирует число PDU, полученных с ошибкой в поле версия. |
3 |
snmpInBadCommunityNames |
Индицирует число PDU, полученных с нечитаемым или нелегальным именем community. |
4 |
snmpInBadCommunityUses |
Полное число SNMP-пакетов, полученных с нечитаемым или нелегальным значение операции для данного имени community. |
5 |
snmpInAsnParsErrs |
Указывает полное число ошибок ASN.1 или BER, которые не могут быть обработаны во входных SNMP-сообщениях |
6 |
snmpInTooBigs |
Указывает число полученных PDU со слишком большим значением поля статус ошибки. |
8 |
snmpInNoSuchNames |
Указывает число PDU, полученных с индикацией ошибки в поле nosuchname. |
9 |
snmpInBadValues |
Указывает число PDU, полученных с индикацией ошибки в поле badvalue. |
10 |
snmpInReadOnlys |
Указывает число PDU, полученных с индикацией ошибки в поле readonly. |
11 |
snmpNnGenErrs |
Указывает число PDU, полученных с generr-полем. |
12 |
snmpInTotalReqVar |
Указывает число объектов MIB, которые были восстановлены. |
13 |
snmpInTotalSetVars |
Указывает число объектов MIB, которые были изменены. |
14 |
snmpInGetRequests |
Указывает число соответствующих pdu, которые были получены. |
15 |
snmpInGetNexts |
Указывает полное число pdu с запросами GetNext |
16 |
snmpInSetRequests |
Указывает полное число pdu, полученных с запросами SET |
17 |
snmpInGetResponses |
Указывает полное число pdu, полученных c откликами на запросы |
18 |
snmpInTraps |
Указывает полное число, полученных и успешно обработанныз TRAP |
19 |
snmpOutTooBig |
Указывает число посланных PDU с полем toobig. |
20 |
snmpOutNoSuchNames |
Указывает число посланных PDU с полем nosuchname. |
21 |
snmpOutBadValues |
Указывает число посланных PDU с полем badvalue. |
22 |
snmpOutGenErrs |
Указывает число посланных PDU с полем genErrs. |
24 |
snmpOutGetRequests |
Указывает число посланных PDU Get-Request |
25 |
snmpOutGetNexts |
Указывает число посланных PDU Get-NEXT |
26 |
snmpOutSetRequests |
Указывает число посланных PDU SET |
27 |
snmpOutGetResponses |
Указывает число посланных PDU откликов |
28 |
snmpOutTraps |
Указывает число посланных PDU TRAPs |
29 |
snmpEnableAuthTraps |
Говорит о том, разрешены или нет ловушки (TRAPS). |
30 |
Таблица 4.4.13.1.2. Переменные IFtable (интерфейсы)
Переменная описания интерфейсов (iftable) | Тип данных | Описание | ifEntry |
IFindex | integer | Список интерфейсов от 1 до ifnumber. | 1 |
IfDescr | displaystring | Текстовое описание интерфейса. | 2 |
IfType | integer | Тип интерфейса, например, 6 - ethernet; 9 - 802.5 маркерное кольцо; 23 - PPP; 28 - SLIP.> | 3 |
IfNumber | integer | Число сетевых интерфейсов. | |
IfMTU | integer | mtu для конкретного интерфейса; | 4 |
IfSpeed | gauge | Скорость в бит/с. | 5 |
IfPhysaddress | physaddress | Физический адрес или строка нулевой длины для интерфейсов без физического адреса (напр. последовательный). | 6 |
IfAdminStatus | [1...3] | Требуемое состояние интерфейса: 1 - включен; 2 - выключен; 3 - тестируется. | 7 |
IfOperStatus | [1...3] | Текущее состояние интерфейса: 1 - включен; 2 - выключен; 3 - тестируется. | 8 |
IfLastchange | timeticks | Sysuptime, когда интерфейс оказался в данном состоянии. | 9 |
IfInOctets | counter | Полное число полученных байтов. | 10 |
IfInUcastpkts | counter | Число пакетов, доставленных на верхний системный уровень (unicast). | 11 |
IfInNUcastpkts | counter | Число пакетов, доставленных на верхний системный уровень (unicast). | 12 |
IfInDiscads | counter | Число полученных но отвергнутых пакетов. | 13 |
IfInErrors | counter | Число пакетов, полученных с ошибкой; | 14 |
IfInUnknownProtos | counter | Число пакетов, полученных с ошибочным кодом протокола; | 15 |
IfOutOctets | counter | Число отправленных байтов; | 16 |
IfOutUcastPkts | counter | Число unicast- пакетов, полученных с верхнего системного уровня; | 17 |
IfOutNucastPkts | counter | Число мультикастинг- и широковещательных пакетов, полученных с верхнего системного уровня; | 18 |
IfOutDiscads | counter | Количество отвергнутых пакетов из числа отправленных; | 19 |
IfOutErrors | counter | Число отправленных пакетов, содержащих ошибки; | 20 |
IfOutQlen | gauge | Число пакетов в очереди на отправку; | 21 |
Ниже представлена таблица цифро-точечного представления переменных, характеризующих состояние интерфейса.
Эта таблица может быть полезной для программистов, занятых проблемами сетевой диагностики.
Название объекта | Цифра-точечное представление |
org | 1.3 |
dod | 1.3.6 |
internet | 1.3.6.1 |
directory | 1.3.6.1.1 |
mgmt | 1.3.6.1.2 |
experimental | 1.3.6.1.3 |
private | 1.3.6.1.4 |
enterprises | 1.3.6.1.4.1 |
security | 1.3.6.1.5 |
snmpV2 | 1.3.6.1.6 |
snmpDomains | 1.3.6.1.6.1 |
snmpProxys | 1.3.6.1.6.2 |
snmpModules | 1.3.6.1.6.3 |
snmpMIB | 1.3.6.1.6.3.1 |
snmpMIBObjects | 1.3.6.1.6.3.1.1 |
snmpTraps | 1.3.6.1.6.3.1.1.5 |
mib-2 | 1.3.6.1.2.1 |
ifMIB | 1.3.6.1.2.1.31 |
interfaces | 1.3.6.1.2.1.2 |
ifMIBObjects | 1.3.6.1.2.1.31.1 |
ifConformance | 1.3.6.1.2.1.31.2 |
ifTableLastChange | 1.3.6.1.2.1.31.1.5 |
ifXTable | 1.3.6.1.2.1.31.1.1 |
ifStackTable | 1.3.6.1.2.1.31.1.2 |
ifStackLastChange | 1.3.6.1.2.1.31.1.6 |
ifRcvAddressTable | 1.3.6.1.2.1.31.1.4 | ifTestTable | 1.3.6.1.2.1.31.1.3 |
ifXEntry | 1.3.6.1.2.1.31.1.1.1 |
ifName | 1.3.6.1.2.1.31.1.1.1.1 |
ifInMulticastPkts | 1.3.6.1.2.1.31.1.1.1.2 |
ifInBroadcastPkts | 1.3.6.1.2.1.31.1.1.1.3 |
ifOutMulticastPkts | 1.3.6.1.2.1.31.1.1.1.4 |
ifOutBroadcastPkts | 1.3.6.1.2.1.31.1.1.1.5 |
ifLinkUpDownTrapEnable | 1.3.6.1.2.1.31.1.1.1.14 | ifHighSpeed | 1.3.6.1.2.1.31.1.1.1.15 |
ifPromiscuousMode | 1.3.6.1.2.1.31.1.1.1.16 |
ifConnectorPresent | 1.3.6.1.2.1.31.1.1.1.17 |
ifAlias | 1.3.6.1.2.1.31.1.1.1.18 |
ifCounterDiscontinuityTime | 1.3.6.1.2.1.31.1.1.1.19 |
ifStackEntry | 1.3.6.1.2.1.31.1.2.1 |
ifStackHigherLayer | 1.3.6.1.2.1.31.1.2.1.1 |
ifStackLowerLayer | 1.3.6.1.2.1.31.1.2.1.2 |
ifStackStatus | 1.3.6.1.2.1.31.1.2.1.3 |
ifRcvAddressEntry | 1.3.6.1.2.1.31.1.4.1 |
ifRcvAddressAddress | 1.3.6.1.2.1.31.1.4.1.1 |
ifRcvAddressStatus | 1.3.6.1.2.1.31.1.4.1.2 |
ifRcvAddressType | 1.3.6.1.2.1.31.1.4.1.3 |
ifTestEntry | 1.3.6.1.2.1.31.1.3.1 |
ifTestId | 1.3.6.1.2.1.31.1.3.1.1 |
ifTestStatus | 1.3.6.1.2.1.31.1.3.1.2 |
ifTestType | 1.3.6.1.2.1.31.1.3.1.3 |
ifTestResult | 1.3.6.1.2.1.31.1.3.1.4 |
ifTestCode | 1.3.6.1.2.1.31.1.3.1.5 |
ifTestOwner | 1.3.6.1.2.1.31.1.3.1.6 |
ifGroups | 1.3.6.1.2.1.31.2.1 |
ifCompliances | 1.3.6.1.2.1.31.2.2 |
ifGeneralInformationGroup | 1.3.6.1.2.1.31.2.1.10 |
ifFixedLengthGroup | 1.3.6.1.2.1.31.2.1.2 |
ifHCFixedLengthGroup | 1.3.6.1.2.1.31.2.1.3 |
ifPacketGroup | 1.3.6.1.2.1.31.2.1.4 |
ifHCPacketGroup | 1.3.6.1.2.1.31.2.1.5 |
ifVHCPacketGroup | 1.3.6.1.2.1.31.2.1.6 |
ifRcvAddressGroup | 1.3.6.1.2.1.31.2.1.7 |
ifStackGroup2 | 1.3.6.1.2.1.31.2.1.11 |
ifCounterDiscontinuityGroup | 1.3.6.1.2.1.31.2.1.13 |
ifGeneralGroup | 1.3.6.1.2.1.31.2.1.1 |
ifTestGroup | 1.3.6.1.2.1.31.2.1.8 |
ifStackGroup | 1.3.6.1.2.1.31.2.1.9 |
ifOldObjectsGroup | 1.3.6.1.2.1.31.2.1.12 | ifCompliance2 | 1.3.6.1.2.1.31.2.2.2 |
ifCompliance | 1.3.6.1.2.1.31.2.2.1 |
ifNumber | 1.3.6.1.2.1.2.1 |
ifTable | 1.3.6.1.2.1.2.2 |
ifEntry | 1.3.6.1.2.1.2.2.1 |
ifIndex | 1.3.6.1.2.1.2.2.1.1 |
ifDescr | 1.3.6.1.2.1.2.2.1.2 |
ifType | 1.3.6.1.2.1.2.2.1.3 |
ifMtu | 1.3.6.1.2.1.2.2.1.4 |
ifSpeed | 1.3.6.1.2.1.2.2.1.5 |
ifPhysAddress | 1.3.6.1.2.1.2.2.1.6 |
ifAdminStatus | 1.3.6.1.2.1.2.2.1.7 |
ifOperStatus | 1.3.6.1.2.1.2.2.1.8 |
ifLastChange | 1.3.6.1.2.1.2.2.1.9 |
ifInOctets | 1.3.6.1.2.1.2.2.1.10 |
ifInUcastPkts | 1.3.6.1.2.1.2.2.1.11 |
ifInNUcastPkts | 1.3.6.1.2.1.2.2.1.12 |
ifInDiscards | 1.3.6.1.2.1.2.2.1.13 |
ifInErrors | 1.3.6.1.2.1.2.2.1.14 |
ifInUnknownProtos | 1.3.6.1.2.1.2.2.1.15 |
ifOutOctets | 1.3.6.1.2.1.2.2.1.16 |
ifOutUcastPkts | 1.3.6.1.2.1.2.2.1.17 |
ifOutNUcastPkts | 1.3.6.1.2.1.2.2.1.18 |
ifOutDiscards | 1.3.6.1.2.1.2.2.1.19 |
ifOutErrors | 1.3.6.1.2.1.2.2.1.20 |
ifOutQLen | 1.3.6.1.2.1.2.2.1.21 |
ifSpecific | 1.3.6.1.2.1.2.2.1.22 |
Таблица 4.4.13.1.3. Переменные IP-группы
Переменная IP-группы
Тип данных
Описание
Код
ipForwarding
integer
Указание на то, что данный объект осуществляет переадресацию (работает как маршрутизатор).
1
IPdefaultTTL
integer
Значение, которое использует IP в поле TTL.
2
IPinreceives
counter
Число полученных дейтограмм.
3
ipInHdrErrors
counter
Число дейтограмм, отвергнутых из-за ошибок формата или неверных адресов или опций, из-за истекшего TTL.
4
ipInHdrErrors
counter
Число дейтограмм, отвергнутых из-за неверного IP-адреса, например, 0.0.0.0, или неподдерживаемого класса, например Е.
5
ipForwDatagrams
counter
Число дейтограмм, для которых данный объект не является местом назначения (маршрутизация отправителя).
6
ipInUnknownProtos
counter
Число дейтограмм с неподдерживаемым кодом протокола.
7
ipInDiscards
counter
Число дейтограмм, отвергнутых из-за переполнения буфера.
8
ipInDelivers
counter
Полное число входных дейтограмм, успешно обработанных на IP-уровне.
9
ipOutRequests
counter
Полное число IP и ICMP дейтограмм, переданных для отправки.
10
ipOutRequests
counter
Полное число IP и ICMP дейтограмм, переданных для отправки.
11
IPoutNoroutes
counter
Число неудач при маршрутизации.
12
ipReasmTimeout
counter
Максимальное число секунд ожидания сборки фрагментов.
13
ipReasmReqds
counter
Число полученных фрагментов
14
ipReasmOKs
counter
Число полученных и успешно собранных IP-дейтограмм
15
ipReasmFails
counter
Число полученных IP-дейтограмм, которые по тем или иным причинам не удалось собрать
16
IPFragOKs
counter
Число успешно фрагментированных IP- дейтограмм.
17
ipFragFails
counter
Число IP- дейтограмм, которые нужно фрагментировать, но сделать это нельзя (например, из-за флага).
18
ipFragCreates
counter
Число IP-дейтограмм фрагментов, сформированных данным объектом.
19
ipAddrTable
counter
Таблица 4.4.13.1.4. Переменные TCP-группы
Переменные TCP-группы
Тип данных
Описание
Код
tcpRtoAlgorithm
integer
Алгоритм выявления таймаута для повторной передачи TCP-пакетов: 1 - ни один из следующих; 2 - постоянное RTO; 3 - стандарт MIL-std-1778; 4 - алгоритм Ван Джакобсона
1
tcpRtoMin
integer
Минимальное допустимое время повторной передачи tcp- пакетов.
2
tcpRtoMax
integer
Максимальное значение тайм-аута в миллисек.
3
tcpMaxConn
integer
Максимальное допустимое число tcp-соединений.
4
tcpActiveOpens
integer
Число TCP-соединений Active-Open
5
tcpPassiveOpens
integer
Число TCP-соединений Passive-Open (из состояния LISTEN)
6
tcpAttemptFails
integer
Число неудачных TCP-соединений
7
tcpEstabResets
integer
Число разрывов TCP-соединений из состояний ESTABLISHED или CLOSE-WAIT
8
tcpCurrEstab
Gauge
Число TCP-соединений, для которых текущее состояние ESTABLISHED или CLOSE-WAIT
9
tcpInSegs
counter
Полное число полученных tcp-сегментов.
10
tcpOutSegs
counter
Полное число посланных сегментов, исключая повторно пересылаемые.
11
tcpRetransSegs
counter
Полное число повторно пересланных сегментов.
12
tcpConnTable
counter
Таблица 1. Примеры характеристик для описания сегмента
Характеристика |
Видео сегмент |
Стационарная область |
Подвижная область |
Видио сегмент |
Время Форма Цвет Текстура Движение Движение камеры Мозаика Характеристики звука |
X . X . X X X . |
. X X X . . . . |
X X X . X . . X |
X . . . . . . X |
Как упомянуто выше, любой сегмент может быть описан с помощью данных формирования, информации об использовании, медиа-данных и текстовой аннотации. Однако специфические характеристики, зависящие от типа сегмента, также допускаются. Примеры специфических характеристик представлены в таблице 1. Большинство дескрипторов (D), соответствующих этим характеристикам может быть получено автоматически из исходного материала. Для этой цели в литературе описано большое число различных средств.
Пример описания изображения представлен на Рисунок 17. Исходные изображения описаны как стационарные области, SR1, которые описаны с помощью данных формирования (заголовок, создатель), информации использования (авторские права), медийной информации (формат файла), а также текстовой аннотации (обобщающей свойства изображения), гистограмм цвета и дескриптора текстуры. Исходная область может быть в дальнейшем разложена на составные области. Для каждого шага декомпозиции, мы указываем, допустимы или нет зазоры и перекрытия. Дерево сегмента состоит из 8 стационарных областей (заметим, что SR8 является одиночным сегментом, составленным из двух связанных сегментов). Для каждой области, на Рисунок 17 показан тип характеристики, которая реализована. Заметим, что в иерархическом дереве не нужно дублировать информацию формирования, использования и пр., так как предполагается, что дочерние сегменты наследуют эти характеристики.
Таблица 4.3.7.2. Протоколы mnp
MNP-1 |
Асинхронная полудуплексная передача данных с побайтовой организацией. Эффективность 70% (2400Кбит/с -> 1680Кбит/c). |
MNP-2 |
Асинхронная дуплексная передача данных с побайтовой организацией. Эффективность 84% (2400кбит/с -> 2000кбит/c) |
MNP-3 |
Синхронная дуплексная передача данных с побитовой организацией. Эффективность 108%. |
MNP-4 |
Адаптивная сборка передаваемых блоков (вариация размера блока) и оптимизация фазы. Эффективность 120% |
MNP-5 |
Помимо новшеств MNP-4 применено сжатие данных. Эффективность 200%. Используется только совместно с MNP-2-4 |
MNP-6 |
Снабжен адаптивностью скорости передачи, рассчитан на работу до 9.6кбит/с. Имеется возможность автоматического переключения из дуплексного режима в полудуплексный и обратно с учетом ситуации |
MNP-7 |
Усовершенствованный алгоритм сжатия данных. Эффективность до 300%. |
MNP-8,9 |
Еще более мощные алгоритмы сжатия |
MNP-10 |
Протокол, ориентированный на работу в сетях с высоким уровнем шумов (сотовые сети, сельские и междугородние линии), надежность достигается благодаря многократным попыткам установить связь, вариации размера пакета и подстройки скорости передачи |
Таблица 4.3.7.4. Протоколы передачи файлов
xmodem |
Протокол (1977г, В. Кристенсен для ОС CP/M). Алгоритм: принимающая ЭВМ посылает символ NAK (ASCII 021) передающая ЭВМ посылает блок информации принимающая ЭВМ проверяет контрольную сумму и, если все в порядке, посылает код ASCII 06 (ACK), в противном случае NAK далее следует повтор передачи при ошибке или посылка следующего блока данных при успехе. Формат блока данных: номер пакета, 128 байт данных и 2 байта контрольной суммы. В Xmodem на принимающей стороне приходится вручную указывать имя файла | |
Kermit |
Наиболее распространенный протокол, использующий блоки переменной длины с максимальным размером 94 байта (программы написаны на Си или ФОРТРАН). Является пакетным протоколом, позволяя пересылать за один раз несколько файлов, для повышения эффективности пересылки использует предварительную архивацию и коррекцию ошибок (Колумбийский университет, 1981г.). | |
Modem7 |
Усовершенствованная версия xmodem для работы по коммутируемым телефонным каналам (передается имя файла). | |
Xmodem/1024 |
Разновидность Xmodem с размером блока данных 1024 байта. | |
Xmodem/CRC |
Разновидность xmodem, использующая 16 битовую crc. | |
Telink |
Передается кроме имени файла, дата, время, можно передать несколько файлов за одну сессию. |
Практически все выше перечисленные протоколы устарели.
Ymodem |
Протокол использует CRC-16, передает имена файлов, размер, дату создания и время, в зависимости от условий передачи размер блока варьируется от 128 до 1024 байт (Чак Форсберг, 1984-85). |
Sealink |
Модификация протокола ymodem. |
Zmodem |
Протокол использует CRC-32 (или CRC-16), динамическое изменение размера блока (32-1024 байта), автоматический выбор протокола обмена, сжатие файлов при пересылке, возобновление передачи с прерванного места в случае разрыва связи. На сегодня это самый совершенный протокол. |
Передача файлов возможна с использованием терминальной программы, это особенно полезно для удаленных терминалов, не поддерживающих протоколы TCP/IP.
Терминальные программы используют один из перечисленных выше протоколов, например, Zmodem. В качестве терминальной программы можно воспользоваться одной из: Term95 (Norton commander 5.0), Bitcom, Teleview, Telix, procomm plus (для DOS и Windows), Mtez, MTE, Zstem-240, Pctalk, Crosstalk (эта и следующие для Windows), Dataline, Hyperaccess.
Чтобы обеспечить безопасность и исключить несанкционированный доступ к сети, можно воспользоваться методом “обратного телефонного вызова”, некоторые модемы реализуют его аппаратно. Метод предполагает, что после установления связи и проверки авторизации связь прерывается, а входной модем сети производит набор номера клиента, который хранится в памяти, и устанавливает связь повторно. Такая схема исключает передачу входного пароля друзьям или знакомым, так как это становится бессмысленным - модем будет пытаться установить связь по номеру вашего домашнего телефона.
Модемы обычно имеют дисплей, который позволяет контролировать работу этого прибора. Модемы разных производителей имеют различные типы дисплеев, ниже приведен список наиболее часто встречающихся индикаторов.
MR | Модем включен и готов к работе (modem ready); |
TR | “Терминал готов” (terminal ready) - включается, когда модем обнаруживает сигнал tdr (data terminal ready), передаваемый вашим программным обеспечением; |
HS | Индикатор включается, когда модем работает на максимальной для него скорости (high speed). |
CD | Обнаружен несущий сигнал (carrier detected), гаснет лишь тогда, когда "партнер положит трубку"; |
AA | Модем включен в режим авто-ответа (auto answer); |
OH | Модем занял линию - “трубка снята” (off-hook); |
RD | Индикатор мигает (receive data), когда ЭВМ принимает данные из своего модема. |
SD | Индикатор (send data) мигает при передаче данных из ЭВМ в модем. |
RL | Индикатор (reliable link) указывает на то, что модем договорился с партнером о типе протокола MNP. |
RD | Принимаются данные (receive data). Индикатор мигает при передаче данных в ЭВМ. |
TS | Модем находится в режиме самотестирования. |
PWR | Включено питание модема. |
V.17 | 9.6 или 14.4 Кбит/с |
V.21 | 200 бит/с (используется только на этапе установления связи) |
V.27ter | 2.4 или 4.8 Кбит/с |
V.29 | 7.2 или 9.6 Кбит/с |
V.527ter | 2400 или 4800 бит/с |
Таблица 4.3.7.3. Разводка стандартных разъемов модема
Сигнал |
Номер контакта (db-9) |
Номер контакта (db-25) |
Назначение |
DCD |
1 |
8 |
Несущая обнаружена (data carrier detected) |
RXD |
2 |
2 |
Передача данных от DCE к DTE(received data) |
TXD |
3 |
3 |
Передача данных от DTE к DCE(transmit data) |
DTR |
4 |
20 |
Данные для передачи готовы (data transfer ready ) |
GND |
5 |
7 |
Земляной контакт |
DSR |
6 |
6 |
Готовность dce к работе (data set ready) |
RTS |
7 |
4 |
Готовность DTE к передаче (request to send) |
CTS |
8 |
5 |
Готовность DCE к передаче (clear to send) |
RI |
9 |
22 |
Индикатор звонка (ring indicator) |
В персональных ЭВМ может быть 2 или 4 последовательных портов (интерфейсов), которые имеют логические имена COM1-COM4, им соответствуют следующие прерывания и адреса:
COM1,3 |
IRQ4 |
0x3f8 |
COM2,4 |
IRQ3 |
0x2f8 |
К телефонной сети модем подключается с помощью 6-х контактного разъема RJ11 (используется 4 контакта).
Модем может находиться в режиме данных (режим по умолчанию) и в командном режиме. Последний используется для реконфигурации модема и подготовки его к работе. Реконфигурация и управление возможны из локальной ЭВМ через последовательный порт, с передней панели модема, или при установленной связи через удаленный модем, если такой режим поддерживается. Переключение в командный режим производится с помощью ESC-последовательности (по умолчанию это три символа “+” с предшествующей и последующей секундной паузой).
При использовании большого числа модемов они для удобства обслуживания объединяются в группы (пулы). Модемный пул представляет в себя стандартный каркас, где размещается какое-то количество бескорпусных модемов. На передней панели находится, как правило, только индикация, выходы в телефонную сеть и разъемы последовательного интерфейса подключаются через заднюю панель. Такой пул содержит в себе обычно управляющий процессор. Так как в настоящее время не существует стандартов на организацию модемных пулов, они ориентированы на использование модемов только определенной фирмы. К пулу может подключаться дисплей, который отображает текущее состояние всех модемов. Процессор может контролировать состояние модемов, устанавливать их режим работы, а в некоторых случаях и выполнять функцию маршрутизатора, управляя встроенным многоканальным, последовательным интерфейсом. В последнем случае такой пул подключается непосредственно к локальной сети (например, Ethernet), а не к ЭВМ. Пул позволяет предотвращать “повисание” и отключение телефонных линий, что заметно повышает надежность системы. Некоторые модемы (например, фирмы Penril) имеют независимые узкополосные (~300 бит/с), дополнительные каналы для дистанционного управления. Такие каналы обладают повышенной устойчивостью, что позволяет сохранять целостность системы даже при временных отключеньях электропитания.
Таблица 4.4.13.1.1. Системные переменные MIB
Системная переменная |
Описание |
Код |
Sysdescr |
Текстовое описание объекта; |
1 |
Sysobjectid |
Идентификатор производителя в рамках дерева 1.3.6.1.4.1 |
2 |
Sysuptime |
Время с момента последней загрузки системы (timeticks); |
3 |
Syscontact |
Имя системного менеджера и способы связи с ним; |
4 |
Sysname |
Полное имя домена; |
5 |
Syslocation |
Физическое местоположение системы; |
6 |
Sysservice |
Величина, которая характеризует услуги, предоставляемые узлом (сумма номеров уровней модели OSI); |
7 |
Таблица, содержащая данные о принимающей стороне
<
Ниже приведено описание таблицы (udptable; index = ,), состоящей из двух простых переменных (read-only).
Имя переменной | Тип данных | Описание |
udplocaladdress | ipaddress | Местный IP-адрес для данного приемника; |
udplocalport | (0 - 65535) | Местный номер порта приемника. |
Таблица 4.3.7.5. Свойства различных систем (модемов) передачи информации.
Название |
Расшифровка |
Длина канала при 24 awg (0,5мм) |
Быстродействие |
Применение |
V.22 V.32 V.34 |
Модемы голосового диапазона |
12 км |
1200 бит/c |
Передача данных |
DSL |
digital subscriber line |
5,4 км |
160 Кбит/с |
Услуги ISDN, передача данных и голоса |
HDSL |
high data rate digital subscriber line |
3,6 км |
1,544 Мбит/с |
t1/e1 каналы, локальные и региональные сети. |
SDSL |
single line digital subscriber line |
- |
1,544 Мбит/с |
t1/e1 каналы, локальные и региональные сети |
ADSL |
asymmetric digital subscriber line |
3,6/5,4 км |
1,5-9 Мбит/с или 16-640 Кбит/c |
Доступ к Интернет, видео, интерактивное мультимедиа. |
VDSL |
very high data rate digital subscriber line |
- |
13-52 Мбит/с или 1,5-2,3 Мбит/с |
То же, что и ADSL плюс HDTV |
Верхние значения в третей колонке для ADSL и VDSL соответствуют нисходящему (асимметричный канал) и дуплексному потокам. HDTV - телевидение высокого разрешения.
Таблица 4.5.10.4. Типы и субтипы почтовых сообщений.
Тип почтового сообщения |
Субтип почтового сообщения |
Описание |
text |
plain |
Неформатированный текст |
richtext |
Текст с простым форматированием, таким как курсив, жирный, с подчеркиванием и т.д. |
|
enriched |
Упрощение, прояснение и усовершенствование richtext |
|
multipart |
mixed |
Сообщение содержит несколько частей, которые обрабатываются последовательно |
parallel |
Сообщение содержит несколько частей, обрабатываемых параллельно |
|
digest |
Краткое содержание почтового сообщения |
|
alternative |
Сообщение содержит несколько частей с идентичным семантическим содержимым |
|
message |
RFC822 |
Содержимое является почтовым сообщением в стандарте RFC-822 |
partial |
Содержимое является фрагментом почтового сообщения |
|
external-body |
Содержимое является указателем на действительный текст сообщения |
|
application |
octet-stream |
Произвольная двоичная информация |
postscript |
PostScript программа |
|
image |
jpeg |
Формат ISO 10918. |
gif |
Формат обмена CompuServe (Graphic Interchange Format). |
|
audio |
basic |
Формат ISO 11172 |
Текст электронного сообщения не передает всех оттенков мыслей и эмоций отправителя, что может вызвать неверное восприятие. Для решения этой проблемы хотя бы частично используются символьные обозначения эмоций. Таблица таких обозначений приведена ниже. Чтобы легче воспринять и запомнить их, посмотрите на страницу, где напечатана таблица, справа.
Символ |
Значение |
:-) |
Улыбка |
:-D |
Смех |
;-) |
Подмигивание |
:-( |
Неудовольствие |
:-< |
Огорчение |
8-) |
Удивление |
:-o |
О, нет! |
:-I |
Безразличие |
:-# |
Вынужденная улыбка |
:-] |
Ухмылка |
:-{) |
Улыбка с усами |
{:-) |
Улыбка с париком |
:-X |
Мой рот на замке |
=:-) |
Панк-рокер |
=:-( |
Настоящий панк-рокер никогда не улыбается |
%^) |
Название для этой улыбки читателям предлагается придумать самостоятельно |
В последнее время большинство почтовых серверов реализуется в среде UNIX, где функцию почтового демона (фонового процесса) выполняет программа sendmail. Эта программа осуществляет переадресацию сообщений от пользователя пользователю и от сервера серверу. Программа эта имеет большие возможности, но ее конфигурирование и использование представляет немалые трудности.
Таблица 4.5.10.1. Внутренние команды почтовой программы UNIX
Субкоманда MAIL |
Описание |
~? |
Отображает весь набор описаний ~-команд |
~b адрес... |
Добавляет адрес в строку "Blind copy" (слепая копия "Bcc:"). |
~c адрес... |
Добавляет адрес(а) в строку "Copy" или "Cc:". |
~d |
Читает содержимое файла dead.letter |
~e |
Вызывает редактор текста |
~f сообщения |
Считывает сообщения |
~h |
Редактирует все строки заголовка. |
~m сообщения |
Считывает сообщения, сдвигает указатель вправо на одну табуляцию |
~p |
Отображает (печатает) текущее сообщение |
~q |
Уход из почты (Quit), эквивалентно двойному Ctrl-C |
~r файл |
Считывает содержимое указанного файла в текст сообщения |
~s subject |
Изменяет содержимое строки Subject |
~t адрес... |
Добавляет адрес в строку "To:". |
~v |
Вызывает альтернативный редактор (то же, что и ~e). |
~w файл |
Записывает текущее сообщение в файл |
~! команда |
Выполняет команду Shell и возвращается к сообщению |
~| команда |
Пропускает текущее сообщение через фильтр |
Если вы напечатаете ~f (без указания номера сообщения), в текст текущего сообщения будет внесено содержимое сообщения, которое вы читали последним. Стандартной формой использования ~f является, например, ~f 5, где 5 - номер сообщения. ~m делает тоже самое, но каждая строка сдвигается на один tab вправо.
В UNIX многие команды имеют разные функции, если они напечатаны строчными или прописными буквами, смотри, например, команды r и R в таблице 4.5.10.2. Не безразлично в UNIX и применение строчных и прописных символов в именах файлов, что бывает существенно, в частности, при работе с FTP-сервером.
Важной командой является SET, которая позволяет изменять системные переменные. Формат использования:
SET переменная=значение (Например, SET EDITOR=/bin/edMe=/bin/eda).
Уже сегодня можно переслать поздравительную цветную открытку вашим знакомым. Возможна по такой схеме пересылка и звуковых писем, лишь бы у вашего адресата была звуковая карта в ЭВМ. Ведутся работы и над протоколами видео-писем (NETBLT).
Тот факт, что электронная почта является наиболее популярным видом сервиса, делает ее объектом непрерывных доработок и усовершенствований. Так в документах RFC-1425, -1426, -1427 предлагается вариант расширения возможностей SMTP (ESMTP). Эта модификация сохраняет совместимость со старыми версиями. Клиент, желающий воспользоваться расширенными возможностями, посылает команду EHLO вместо HELO. Если сервер поддерживает ESMTP, он выдаст код-отклик 250. Этот вид отклика является многострочным, что позволяет серверу сообщить о видах сервиса, которые он поддерживает. Например:
250-8BITMIME (RFC-1426)
250-EXPN (RFC-821)
250-SIZE (RFC-1427)
250-HELP (RFC-821)
250-XADR
4.2.2. Текстуальный формат
Расширяемый текстовой формат MPEG-4 XMT (Extensible Textual format) является базовым для представления MPEG-4 описаний сцен, использующих текстовой синтаксис. XMT позволяет авторам текста обмениваться его содержимым друг с другом. Консорциумом Web3D разработаны средства обеспечения совместимости с расширяемым X3D (Extensible 3D), и интеграционным языком синхронизованного мультимедиа SMIL (Synchronized Multimedia Integration Language) от консорциума W3C.
Формат XMT может быть изменен участниками SMIL, VRML, и MPEG-4. Формат может быть разобран и воспроизведен непосредственно участником W3C SMIL, преобразован в Web3D X3D и заново воспроизведен участником VRML, или компилирован в презентацию MPEG-4, такую как mp4, которая может быть затем воспроизведена участником MPEG-4. Ниже описано взаимодействие с XMT. Это описание содержит в себе MPEG-4, большую часть SMIL, масштабируемую векторную графику (Scalable Vector Graphics), X3D, а также текстуальное представление описания MPEG-7 (смотри http://www.cselt.it/mpeg, где имеется документация на стандартe MPEG-7).
XMT содержит два уровня текстуального синтаксиса и семантики: формат XMT-A и формат XMT-U.
XMT-A является версией MPEG-4, базирующейся на XML, содержащей субнабор X3D. В XMT-A содержится также расширение MPEG-4 для X3D, что бы работать с некоторыми специальными средствами MPEG-4. XMT-A предоставляет прямое соответствие между текстовым и двоичным форматами.
XMT-U является абстракцией средств MPEG-4 высокого уровня, базирующейся на W3C SMIL. XMT предоставляет по умолчанию соответствие U и A.
6.1.3. Тестирование стабильности временного разрешения
6.1.3.1. Простой продвинутый профайл реального времени ARTS (Advanced Real-Time Simple) (версия 2)
В данном тесте исследовались характеристики видео кодека, использующего технику преобразования с динамическим разрешением, которая адаптирует разрешение видео материала к обстоятельствам в реальном времени. Материал активной сцены кодировался при скоростях 64 кбит/с, 96 кбит/с и 128 кбит/с. Результаты показывают, что при 64 кбит/с, он превосходит простой профайл, работающий при 96 кбит/с, а при 96 кбит/с, визуальное качество эквивалентно полученному для простого профайла при 128 кбит/с.
6.1.2. Тесты устойчивости к ошибкам
6.1.2.1. Простой профайл (версия 1)
Устойчивость видео к ошибкам в простом профайле MPEG-4 была оценена в ходе тестов, которые симулируют видео MPEG-4, выполненных при скоростях между 32 кбит/с и 384 кбит/с. Испытания произведены при BER < 10-3, и средней длине блока ошибок около 10мс. Тестовая методология базировалась на непрерывной оценке качества в течение 3 минут.
Результаты показывают, что в среднем качество видео, полученное для мобильного канала, является высоким, что воздействие ошибок в видео MPEG-4 остается локальным, и что качество быстро восстанавливается по завершении блока ошибок.
6.1.2.2. Простой продвинутый профайл реального времени ARTS (Advanced Real-Time Simple) (версия 2)
Устойчивость видео к ошибкам в MPEG-4 профайле ARTS была оценена в ходе тестов, аналогичных описанным выше, при скоростях между 32 кбит/с и 128 кбит/с. В этом случае, остаточный уровень ошибок достигал 10-3, а средняя длительность блока ошибок была около 10 мс или 1 мс.
Результаты испытаний показывают превосходство профайла ARTS над простым
профайлом для всех параметров исследования. Профайл ARTS предпочтительнее простого по времени восстановления после прохождения блока ошибок.
Рисунок 27. Тип приложения медиа транскодирования. Из исходной DB создается транскодированная база данных, соответствующая описаниям и опционно запросу.
3.6.5.4. Приложение описания фильтрации
Приложение фильтрации описаний может относиться к типу выборки или клиента, в зависимости оттого сгенерирован или использован исследуемый дескриптор (DUT). В обоих случаях описания входной базы данных фильтруются на основе регламентаций запроса. Результирующие отфильтрованные описания записываются затем в выходные файлы.
3. Типы доступа к внешнему телу
RFC-2046 определяет тип среды message/external-body, в рамках которой объект MIME может действовать, как указатель на реальное информационное тело сообщения. Каждый указатель message/external-body специфицирует тип доступа, который определяет механизм получения реального тела сообщения. RFC-2046 определяет исходный набор типов доступа, но допустимо описание нового механизма доступа в процессе регистрации нового типа среды.
3.1. Требования к регистрации
Спецификации нового типа доступа должны отвечать ряду требований, описанных ниже.
Каждый тип доступа должен иметь уникальное имя. Это имя появляется в параметре типа доступа в поле заголовка типа содержимого message/external-body, и должно соответствовать синтаксису параметров MIME.
Все протоколы транспортные средства и процедуры, используемые данным типом доступа, должны быть описаны в самой спецификации типа доступа или в какой-то другой общедоступной спецификации, достаточно подробно, чтобы этим мог воспользоваться квалифицированный программист. Использование секретных и/или частных методов доступа категорически запрещено. Ограничения, введенные документом RFC-1602 на стандартизацию патентованных алгоритмов, также должны быть учтены.
Все типы доступа должны быть описаны в RFC. RFC может быть информационным, а не обязательно описанием стандарта.
Любые соображения безопасности, которые возникают в связи с реализацией типа доступа, должны быть подробно описаны. Совсем не нужно, чтобы метод доступа был безопасным или лишенным рисков, но известные риски должны быть идентифицированы.
3.2. Процедура регистрации
Регистрация нового типа доступа начинается с создания проекта RFC. Далее осуществляется рассылка проекта через список подписки ietf-types@iana.org. Для получения откликов выделяется две недели. Этот подписной лист создан для целей обсуждения предлагаемых типов среды и доступа. Предлагаемые типы доступа не должны применяться до момента формальной регистрации.
Когда двухнедельный период истечет, ответственное лицо, назначенное региональным директором IETF, переадресует запрос iana@isi.edu, или отклоняет его из-за существенных возражений, высказанных в процессе обсуждения.
Решения принятые ответственным лицом IETF рассылаются всем через подписной лист IETF-types всем заинтересованным лицам в пределах двух недель. Это решение может быть обжаловано в IESG.
Утвержденная спецификация типа доступа должна быть опубликована в качестве документа RFC. Информационные RFC публикуются путем посылки их по адресу "rfc-editor@isi.edu".
3.3. Расположение списка зарегистрированных типов доступа
Зарегистрированные спецификации типа доступа доступны через анонимное FTP на сервере ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/. Все зарегистрированные типы доступа включаются в перечень типов доступа, периодически публикуемый в документе "Assigned Numbers" RFC-1700.
4. Транспортное кодирование
Транспортное кодирование представляет собой преобразование, применяемое к типам среды MIME после конвертации в каноническую форму. Транспортное кодирование используется в нескольких целях.
(1) | Многие виды транспорта, особенно пересылка сообщений, могут обрабатывать только данные, состоящие из относительно коротких строк текста. Существуют также строгие ограничения на то, какие символы могут использоваться в этих строках текста. Некоторые виды транспортировки допускают использование только субнабора US-ASCII, а другие не могут работать с некоторыми символьными последовательностями. Транспортное кодирование используется, для того чтобы преобразовать двоичные данные в текстовую форму. Примеры такого сорта транспортного кодирования включают применение base64 и закавыченных строк печатных символов, определенных в RFC-2045. |
(2) | Изображение, аудио, видео и даже объекты приложений имеют иногда овольно большой размер. Алгоритмы сжатия часто весьма эффективны для сокращения объектов большого размера. Транспортное кодирование может использоваться также, для того чтобы с помощью универсальных алгоритмов сжатия без потерь сократить размер MIME-объектов. |
(3) | Транспортное кодирование может быть определено, как средства представления существующих форматов кодирования в контексте MIME. |
Стандартизация большого числа видов транспортного кодирования представляется серьезным барьером для обеспечения совместной работы различных узлов. Несмотря ни на что, определена процедура для обеспечения средств определения дополнительных транспортных кодировок.
4.1. Требования к транспортному кодированию
Спецификации транспортного кодирования должны отвечать определенному числу требований, описанных ниже.
Каждый тип транспортного кодирования должен иметь уникальное имя. Это имя записывается в поле заголовка Content-Transfer-Encoding и должно согласовываться с его синтаксисом.
Все алгоритмы, используемые при транспортном кодировании (напр. преобразование к печатному виду или сжатие) должны быть описаны в спецификациях транспортного кодирования.
Использование секретных алгоритмов транспортного кодирования категорически запрещено. Ограничения, накладываемые документом RFC-1602 на стандартизацию патентованных алгоритмов должно непременно учитываться.
Все виды транспортного кодирования должны быть применимы для произвольной последовательности октетов, имеющей любую длину. Зависимость от конкретного входного формата не допускается.
Не существует требования, чтобы транспортное кодирование приводило к определенному выходному формату. Однако выходной формат каждого транспортного кодирования должен быть исчерпывающе документирован. В частности, каждая спецификация должна ясно объявить, являются ли выходные данные 7-битовыми, 8-битовыми или просто двоичными.
Все виды транспортного кодирования должны быть полностью инвертируемыми на любой платформе. Всегда должна иметься возможность преобразовать данные к исходному виду с помощью соответствующей декодирующей процедуры. Заметим, что эти требования исключают все виды сжатия с частичной потерей информации и все виды шифрования в качестве разновидностей транспортного кодирования.
Все виды транспортного кодирования должны предоставлять некоторый вид новых функциональных возможностей.
4.2. Процедура определения транспортного кодирования
Определение нового вида транспортного кодирования начинается с создания проекта стандартного документа RFC. RFC должен определить транспортное кодирование точно и исчерпывающе и предоставить необходимое обоснование введения этого вида кодирования. Эта спецификация должна быть представлена на рассмотрение IESG. IESG может
(1) | отклонить спецификацию, как неприемлемую для стандартизации, |
(2) | одобрить создание рабочей группы IETF для разработки спецификации, согласно действующей процедуре IETF, или |
(3) | принять спецификацию, так как она есть, и поместить ее в перечень стандартов. |
10.2.9. Транспортный поток звука
Транспортный поток MPEG-4 аудио определяет механизм передачи аудио потоков MPEG-4 без использования систем MPEG-4 и предназначен исключительно для аудио приложений. Транспортный механизм использует двухуровневый подход, а именно уровни мультиплексирования и синхронизации. Уровень мультиплексирования (Low-overhead MPEG-4 Audio Transport Multiplex: LATM) управляет мультиплексированием нескольких информационных полей MPEG-4 аудио и аудио конфигурационной информации. Уровень синхронизации специфицирует синтаксис транспортного потока MPEG-4 аудио, который называется LOAS (Low Overhead Audio Stream – аудио поток с низкой избыточностью). Интерфейсный формат для транспортного уровня зависит от ниже лежащего коммуникационного уровня.
4.2.3. Улучшенная модель синхронизации
Продвинутая модель синхронизации (обычно называемая ‘FlexTime’) поддерживает синхронизацию объектов различного происхождения с возможно разной временной шкалой. Модель FlexTime специфицирует временную привязку, используя гибкую модель с временными ограничениями. В этой модели, медиа-объекты могут быть связаны друг с другом в временном графе с использованием таких ограничений как "CoStart", "CoEnd", или "Meet". И, кроме того, для того чтобы обеспечить определенную гибкость и адаптацию к этим ограничениям, каждый объект может иметь адаптируемую длительность с определенными предпочтениями для растяжения и сжатия, которые могут быть применены.
Модель FlexTime базируется на так называемой метафоре "пружины". Пружина имеет три ограничения: минимальная длина, менее которой она не сжимается, максимальная длина, при которой она может оборваться, и оптимальная длина, при которой она остается ни сжатой, ни растянутой. Следуя модели пружины, временные воспроизводимые медиа-объекты могут рассматриваться как пружины, с набором длительностей воспроизведения, соответствующих этим трем ограничениям пружины. Оптимальная длительность воспроизведения (оптимальная длина пружины) может рассматриваться как предпочтительный выбор автора для длительности воспроизведения медиа-объекта. Участник, где возможно, поддерживает длительность воспроизведения настолько близко к оптимальному значению, насколько позволяет презентация, но может выбрать любую длительность между минимальной и максимальной, как это специфицировал автор. Заметим, что поскольку растяжение или сжатие длительности в непрерывных средах, например, для видео, подразумевает соответствующее замедление или ускорение воспроизведения, для дискретных сред, таких как статическое изображение, сжатие или растяжение сопряжено в основном с модификацией периода рэндеринга.
8.3. Улучшенная модель синхронизации (FlexTime)
Модель FlexTime (Advanced Synchronization Model) расширяет традиционную модель хронирования MPEG-4, чтобы разрешить синхронизацию большого числа потоков и объектов, таких как видео, аудио, текст, графика, или даже программы, которые могут иметь разное происхождение.
Традиционная модель синхронизации MPEG-4 первоначально была сконструирована для широковещательных приложений, где синхронизация между блоками доступа осуществляется через "жесткие" временные метки и эталонные часы. В то время как этот механизм предоставляет точную синхронизацию внутри потока, он терпит неудачу при синхронизации потоков, приходящих из разных источников (и возможно с разными эталонными часами) как это имеет место в случае большинства приложений Интернет и в более сложных широковещательных приложениях.
Модель FlexTime позволяет разработчику материала специфицировать простые временные соотношения для выбранных объектов MPEG-4, таких как "CoStart," "CoEnd," и "Meet." Автор материала может также специфицировать ограничения гибкости для объектов MPEG-4, как если бы объекты были растяжимыми пружинами. Это позволяет синхронизовать большое число объектов согласно специфицированным временным соотношениям.
Наибольшую эффективность внедрение этой техники может дать в случае приложений Интернет, где нужно синхронизовать большое число источников на стороне клиента.
9.6. Улучшенная стабильность временного разрешения с низкой задержкой буферизации
Еще одной новой методикой является DRC (Dynamic Resolution Conversion), которая стабилизирует задержку буферизации при передаче путем минимизации разброса числа кодовых бит VOP на выходе. Предотвращается отбрасывание больших пакетов, а кодировщик может контролировать временное разрешение даже в высоко активных сценах.
8.2.3. Управление буфером
Чтобы предсказать, как декодер будет себя вести, когда он декодирует различные элементарные потоки данных, которые образуют сессию MPEG-4, модель системного декодера (Systems Decoder Mode) позволяет кодировщику специфицировать и мониторировать минимальные буферные ресурсы, необходимые для декодирования сессии. Требуемые буферные ресурсы передаются декодеру в объектных дескрипторах во время установления сессии MPEG-4, так что декодер может решить, может ли он участвовать в этой сессии.
При управлении конечным буферным пространством модель позволяет отправителю, например, передавать данные, не привязанные к реальному времени, досрочно, если имеется достаточно места в буфере со стороны приемника. Запомненные данные будут доступны в любое время, позволяя использовать для информации реального времени при необходимости большие ресурсы канала.
4.4.13.1 Управляющая база данных MIB
MIB определяет, например, что IP программное обеспечение должно хранить число всех октетов, которые приняты любым из сетевых интерфейсов, управляющие программы могут только читать эту информацию.
Согласно нормативам MIB управляющая информация делится на восемь категорий (см. также Рисунок 4.4.13.1.1):
MIB-категория включает в себя информацию о
MIB-категория | Описание | Код |
system | Операционная система ЭВМ или маршрутизатора. | 1 |
Interfaces | Сетевой интерфейс. | 2 |
addr.trans | Преобразование адреса (напр., с помощью arp). | 3 |
IP | Программная поддержка протоколов Интернет. | 4 |
ICMP | Программное обеспечение icmp-протокола. | 5 |
TCP | Программное обеспечение TCP-протокола. | 6 |
UDP | Программное обеспечение UDP-протокола. | 7 |
EGP | Программное обеспечение EGP-протокола. | 8 |
SNMP | Программное обеспечение SNMP-протокола. | 11 |
10.2.6. Устойчивое к ошибкам HVXC
Объект HVXC, устойчивый к ошибкам (ER) поддерживается средствами параметрического кодирования голоса (ER HVXC), которые предоставляют режимы с фиксированными скоростями обмена (2.0-4.0 кбит/с) и режим с переменной скоростью передачи (<2.0 кбит/с, <4.0 кбит/с) в раках масштабируемой и не масштабируемой схем. В версии 1 HVXC, режим с переменной скоростью передачи поддерживается максимум 2.0 кбит/с, а режим с переменной скоростью передачи в версии ER HVXC 2 дополнительно поддерживается максимум 4.0 кбит/с. ER HVXC обеспечивает качество передачи голоса международных линий (100-3800 Hz) при частоте стробирования 8кГц. Когда разрешен режим с переменной скоростью передачи, возможна работа при низкой средней скорости передачи. Речь, кодированная в режиме с переменной скоростью передачи при среднем потоке 1.5 кбит/с, и типовом среднем значении 3.0 кбит/с имеет существенно то же качество, что для 2.0 кбит/с при фиксированной скорости и 4.0 кбит/с, соответственно. Функциональность изменения тона и скорости при декодировании поддерживается для всех режимов. Кодировщик речи ER HVXC ориентирован на приложения от мобильной и спутниковой связи, до IP-телефонии, и голосовых баз данных.
9.5. Устойчивость в среде, предрасположенной к ошибкам
Разработанная в MPEG новая методика, названная NEWPRED ('new prediction' – новое предсказание), предоставляет быстрое восстановление после ошибок в приложениях реального времени. Она использует канал от декодера к кодировщику. Кодировщик переключает эталонные кадры, приспосабливаясь к условиям возникновения ошибок в сети. Методика NEWPRED обеспечивает высокую эффективность кодирования. Она была проверена в условиях высоких потоков ошибок:
• Короткие всплески ошибок в беспроводных сетях (BER= 10-3, длительность всплеска 1мс)
• Потери пакетов в Интернет (вероятность потери = 5%)
9.14. Устойчивость в среде, предрасположенной к ошибкам
MPEG-4 обеспечивает устойчивость к ошибкам, чтобы позволить доступ к изображениям и видео данным через широкий круг устройств памяти и передающих сред. В частности, благодаря быстрому росту мобильных телекоммуникаций, необычайно важно получить доступ к аудио и видео информации через радио сети. Это подразумевает необходимость успешной работы алгоритмов сжатия аудио и видео данных в среде предрасположенной к ошибкам при низких скоростях передачи (т.е., ниже 64 кбит/с).
Средства противостояния ошибкам, разработанные для MPEG-4 могут быть разделены на три основные группы: ресинхронизация, восстановление данных и подавления влияния ошибок. Следует заметить, что эти категории не являются уникальными для MPEG-4, они широко используются разработчиками средств противодействия ошибкам для видео.
8.3.3.1. Узел TemporalTransform
TemporalTransform поддерживает синхронизацию узлов в пределах сцены с медиа потоком, или его сегментом, и поддерживает гибкое преобразование ко времени сцены. Этот группирующий узел может гибко поддерживать замедление, ускорение, замораживание или смещение временной шкалы сцены для рэндеринга узлов содержащихся в ней. Его дочернее поле может содержать список узлов типа SF3Dnode, а узел может влиять на замедление, ускорение, замораживание или смещение временной шкалы композитора, когда он осуществляет рэндеринг дочерних узлов, которые преобразованы этим узлом. Кроме того, этот узел имеет поле url, которое может ссылаться на элементарный поток или его сегмент и в этом случае, узел воздействует на временную шкалу потока, указанного в ссылке.
8.3.3.2. Узел TemporalGroup
Узел TemporalGroup специфицирует временное соотношение между заданным числом TemporalTransforms, чтобы выровнять временные шкалы узлов, в графе сцены. Временная настройка среды с целью удовлетворения ограничений и обеспечения гибкости осуществляется на уровне sync. TemporalGroup может рассматривать временные свойства его дочек и когда все они готовы, а временные ограничения выполнены, может быть дано разрешение на их воспроизведение.
6. Верификационное тестирование: проверка работы MPEG
MPEG выполняет верификационные тесты для проверки того, предоставляет ли стандарт то, что должно быть. Результаты испытаний можно найти на базовой странице MPEG: http://www.cselt.it/mpeg/quality_tests.htm
2.4. Видео-система
Стандарт MPEG-4 Видео допускает гибридное кодирование естественных (пиксельных) изображений и видео вместе с синтезированными сценами (генерированными на ЭВМ). Это, например, допускает виртуальное присутствие участников видеоконференций. Видео стандарт содержит в себе средства и алгоритмы, поддерживающие кодирование естественных (пиксельных) статических изображений и видео последовательностей, а также средства поддержки сжатия искусственных 2-D и 3-D графических геометрических параметров.
3.2. Видео-системы
3.2.1. Натуральное видео
Видео MPEG-4 версия 2 добавляет новые возможности в следующих областях:
увеличенная гибкость объектно-ориентированного масштабируемого кодирования,
улучшенная эффективность кодирования,
улучшенная стабильность временного разрешения при низкой задержке буферизации,
улучшенная устойчивость к ошибкам,
кодирование нескольких изображений: промежуточные или стереоскопические изображения будут поддерживаться на основе эффективного кодирования нескольких изображений или видео последовательностей. Частным примером может служить кодирование стереоскопического изображения или видео путем сокращения избыточности информации за счет малого различия изображений в стереопаре.
6.1. Видео
6.1.1. Тесты эффективности кодирования
6.1.1.1. Низкие и средние скорости передачи бит (версия 1)
При испытаниях для низкой и средней скорости передачи, рассматривались последовательности кадров, которые следуют стандарту MPEG-1. (MPEG-2 будет идентичным для прогрессивных последовательностей за исключением того, что MPEG-1 немного более эффективен, так как имеет несколько меньшую избыточность заголовков). Тест использует типовую тестовую последовательность для разрешений CIF и QCIF, закодированный с идентичными условиями по скорости передачи для MPEG-1 и MPEG-4. Тест был выполнен для низких скоростей от 40 кбит/с до 768 кбит/с.
Тесты эффективности кодирования показывают полное превосходство MPEG-4 перед MPEG-1 как на низкой, так и на средней скорости передачи.
6.1.1.2. Кодирование, базирующееся на содержимом (версия 1)
Верификационные тесты для кодирования, базирующегося на содержимом, сравнивают визуальное качество кодирования object-based и frame-based. Главным соображением было гарантировать, чтобы object-based кодирование можно было поддерживать без ухудшения визуального качества. Содержимое теста было выбрано так, чтобы перекрыть широкий спектр условий моделирования, включая видео сегменты с различными типами движения и сложностью кодирования. Кроме того, условия теста были выбраны так, чтобы перекрыть низкие скорости передачи в диапазоне от 256 кбит/с до 384 кбит/с, и высокие скорости передачи в диапазоне от 512кбит/с до 1.15 Мбит/с. Результаты тестов ясно продемонстрировали, что объектно-ориентированная функциональность, предоставляемая MPEG-4, не имеет избыточности или потерь визуального качества, по сравнению с кодированием frame-based. Не существует статистически значимого различия между вариантами object-based и frame-based.
6.1.1.3. Профайл продвинутой эффективности кодирования ACE (Advanced Coding Efficiency) (версия 2)
Формальные верификационные тесты профайла ACE (Advanced Coding Efficiency) были выполнены с целью проверки, улучшают ли эффективность кодирования три новые средства версии 2, включенные в визуальный ACE профайл MPEG-4 версии 2 (компенсация общего перемещения, компенсация перемещения на четверть пикселя и адаптированное к форме преобразование DCT), по сравнению с версией 1.
Тесты исследуют поведение ACE профайла и главного визуального профайла MPEG-4 версия 1 в режимах object-based и frame-based при низкой скорости передачи, frame-based при высокой скорости передачи. Полученные результаты показывают преимущество ACE профайла перед главным профайлом. Ниже приведены некоторые детали сопоставления работы этих профайлов:
Для объектно-ориентированного случая, качество, предоставляемое профайлом ACE при 256 кбит/с равно качеству, обеспечиваемому главным профайлом при скорости 384 кбит/с.
Для кадр-ориентированного случая, качество, предоставляемое профайлом ACE при 128 кбит/с и 256 кбит/с равно качеству, обеспечиваемому главным профайлом при скорости 256 кбит/с и 384 кбит/с соответственно.
Для кадр-ориентированного случая при высоких скоростях передачи, качество, предоставляемое профайлом ACE при 768 кбит/с равно качеству, обеспечиваемому главным профайлом при 1024 кбит/с.
При интерпретации этих результатов, нужно заметить, что главный профайл MPEG-4 более эффективен, чем MPEG-1 и MPEG-2.
4.1. Визуальная область системы
В визуальной области подготавливается добавление следующих методик:
Масштабируемость пространственного разрешения (Fine Grain) находится на фазе голосования, с предложенными ‘Профайлами поточного видео’ (‘Advanced Simple’ и ‘Fine Grain Scalability’). Масштабируемость пространственного разрешения представляет собой средство, которое допускает небольшие изменения качества путем добавления или удаления слоев дополнительной информации. Это полезно во многих ситуациях, особенно для организации потоков, но также и для динамического (‘статического’) мультиплексирования предварительно закодированных данных в широковещательной среде.
Средства для использования MPEG-4 в студии. Для этих целей были приняты меры для сохранения некоторой формы совместимости с профайлами MPEG-2. В настоящее время, простой студийный профайл находится на фазе голосования (Simple Studio Profile), это профайл с кодированием только I-кадра при высоких скоростях передачи данных (несколько сот Мбит/с), который использует кодирование формы (shape coding). Ожидается добавление профайла ядра студии (Core Studio Profile) (с I и P кадрами).
Изучаются цифровые камеры. Это приложение потребует truly lossless coding, и not just the visually lossless that MPEG-4 has provided so far. A Preliminary Call for Proposals was issued in October 2000.
5.1. Визуальные профайлы
Визуальная часть стандарта предоставляет профайлы для кодирования естественного, синтетического и гибридного типов изображений. Существует пять профайлов для естественного видео-материала:
1. Простой визуальный профайл обеспечивает эффективное, устойчивое к ошибкам кодирование прямоугольных видео объектов, подходящих для приложений мобильных сетей, таких как PCS и IMT2000.
2. Простой масштабируемый визуальный профайл добавляет поддержку кодирования временных и пространственных, масштабируемых объектов в простом визуальном профайле. Он полезен для приложений, которые обеспечивают услуги на более чем одном уровне качества, связанных с ограничениями скорости передачи данных или ресурсами декодера, такими как использование Интернет и программное декодирование.
3. Центральный визуальный профайл добавляет поддержку кодировки время-масштабируемых объектов произвольной формы в простой визуальный профайл. Он полезен для приложений, осуществляющих относительно простую интерактивность (приложения Интернет мультимедиа).
4. Главный визуальный профайл добавляет поддержку кодирования черезстрочных, полупрозрачных, и виртуальных объектов в центральном визуальном профайле. Он полезен для интерактивного широковещательного обмена (с качеством для развлечений) и для DVD-приложений.
5. N-битный визуальный профайл добавляет поддержку кодирования видео объектов, имеющих пиксельную глубину в диапазоне от 4 до 12 бит в главный визуальный профайл. Он удобен для использования в приложениях для наблюдения.
Профайлами для синтетических и синтетико-натуральных гибридных визуальных материалов являются:
6. Простой визуальный профайл для анимации лица (Simple Facial Animation) предоставляет простые средства анимации модели лица, удобные для таких приложений как аудио/видео презентации лиц с ухудшенным слухом.
7. Визуальный масштабируемый профайл для текстур (Scalable Texture Visual)
предоставляет пространственное масштабируемое кодирование статических объектов изображений (текстур), полезное для приложений, где нужны уровни масштабируемости, такие как установление соответствия между текстурой и объектами игр, а также работа с цифровыми фотокамерами высокого разрешения.
9.14.2. Восстановление данных
После того как синхронизация восстановлена, средства восстановления данных пытаются спасти данные, которые в общем случае могут быть потеряны. Эти средства являются не просто программами коррекции ошибок, а техникой кодирования данных, которая устойчива к ошибкам. Например, одно конкретное средство, которое было одобрено видео группой (Video Group), является обратимыми кодами переменной длины RVLC (Reversible Variable Length Codes). В этом подходе, кодовые слова переменной длины сконструированы симметрично, так что они могут читаться как в прямом, так и в обратном направлении.
Пример, иллюстрирующий использование RVLC представлен на Рисунок 13. Вообще, в ситуации, когда блок ошибок повредил часть данных, все данные между двумя точками синхронизации теряются. Однако, как показано на Рисунок 13, RVLC позволяет восстановить часть этих данных. Следует заметить, что параметры, QP и HEC, показанные на рисунке, представляют поля, зарезервированные в заголовке видео пакета для параметра квантования и кода расширения заголовка, соответственно.
Рисунок 8. Возможная логическая структура сцены
Как объекты позиционируются в пространстве и времени. В модели MPEG-4, аудиовизуальные объекты имеют протяженность в пространстве и во времени. Каждый медиа-объект имеет локальную координатную систему. Локальная координатная система объекта является той, в которой объект имеет фиксированное пространственно-временное положение и шкалу. Локальная координатная система служит в качестве указателя для манипулирования медиа-объектом в пространстве и во времени. Медиа-объекты позиционируются на сцене путем спецификации координатного преобразования из локальной координатной системы объекта в глобальную систему.
Выбор значения атрибута. Индивидуальные медиа-объекты и узлы описания сцены демонстрируют набор параметров композиционному слою через который может частично контролироваться их поведение. Среди примеров можно назвать понижение звука (pitch), цвет для синтетических объектов, активация или дезактивация информации улучшения для масштабируемого кодирования и т.д.
Другие преобразования медиа-объектов. Как упомянуто выше, структура описания сцены и семантика узла подвержены сильному влиянию VRML, включая его модель событий. Это предоставляет MPEG-4 очень богатый набор операторов конструирования сцены, включая графические примитивы, которые могут использоваться для построения сложных сцен.
Рисунок 25. Выборка для приложения медийного типа. Описание извлекается из входных медийных данных
3.6.5.2. Приложение поиска и извлечения
Приложение поиска и получения данных, показанное на Рисунок 26, относится к типу клиентского приложения. Сначала все описания базы данных, которые могут быть извлечены из медиа приложения, декодируются и загружаются в память. Из медиа данных с помощью средства выборки может быть извлечено и описание запроса. С другой стороны запрос может быть загружен непосредственно из файла. После получения всех входных данных, запрос обрабатывается для всех элементов базы данных, а результирующие расстояния (значения отличия) используются для сортировки данных согласно уровню соответствия запросу. Наконец, сортированный список записывается в качестве медиа базы данных в файл.
8.1.1. Вычислительная модель DMIF
Когда приложение запрашивает активацию услуги, оно использует сервисный примитив DAI, и формирует соответствующую сессию. Реализация DMIF устанавливает контакт с соответствующим партнером (который концептуально может быть либо удаленным, либо эмулируемым локальным партнером) и формирует вместе с ним сетевую сессию. В случае широковещательного и локального сценариев, способ формирования и управления сессией находится вне зоны ответственности данного документа. В случае интерактивного сценария с удаленным сервером, DMIF использует свой сигнальный механизм для формирования и управления сессией, например, сигнальный механизм ATM. Приложения партнеров используют эту сессию для установления соединения, которое служит для передачи прикладных данных, например, элементарных потоков MPEG-4.
Когда приложению нужен канал, оно использует примитивы канала DAI, DMIF транслирует эти запросы в запросы соединения, которые являются специфическими для конкретных запросов сетевых реализаций. В случае сценариев широковещания и локальной памяти, метод установления соединения и последующего управления находится за пределами регламентаций MPEG-4. В случае сетевого сценария напротив, DMIF использует свой сигнальный механизм для формирования и управления соединением. Это соединение используется приложением для целей доставки данных.
На Рисунок 6 предоставлена схема активации верхнего уровня и начало обмена данными. Этот процесс включает в себя четыре этапа:
Приложение-инициатор посылает запрос активизации услуги своему локальному слою DMIF – коммуникационное соединение между приложением-инициатором и его локальным партнером DMIF устанавливается в контрольной плоскости (1)
Партнер-инициатор DMIF запускает сетевую сессию с партнером-адресатом DMIF - коммуникационное соединение партнером-инициатором DMIF и партнером-адресатом DMIF устанавливается в контрольной плоскости (2).
Партнер-адресат DMIF идентифицирует приложение-адресат и переадресует запрос активации услуги - коммуникационное соединение между партнером-адресатом DMIF и приложением-адресатом устанавливается в контрольной плоскости (3)
Приложения партнеров создают каналы (запросы передаются через коммуникационные пути 1, 2 и 3). Результирующие каналы в пользовательской плоскости (4) используются приложениями для реального информационного обмена. DMIF вовлечена во все четыре этапа.
Рисунок 6. Вычислительная модель DMIF
Слой DMIF автоматически определяет, предполагается ли предоставление данной услуги удаленным сервером в конкретной сети, например, в IP, или ATM, широковещательной сетью, или устройством локальной памяти: выбор основывается на адресной информации партнера, предоставляемой приложением в качестве части URL, переданной DAI.
1.5. Взаимодействие с медийными объектами
Пользователь видит сцену, которая сформирована согласно дизайну разработчика. В зависимости от степени свободы, предоставленной разработчиком, пользователь имеет возможность взаимодействовать со сценой. Пользователю могут быть разрешены следующие операции:
изменить точку наблюдения/слушания на сцене;
перемещать объекты по сцене;
вызывать последовательность событий путем нажатия кнопки мыши на определенных объектах, например, запуская или останавливая поток данных;
выбирать предпочтительный язык, когда такой выбор возможен;
8.6. Взаимодействие с пользователем
MPEG-4 позволяет пользователю взаимодействие с отображаемым материалом. Это взаимодействие может быть разделено на две главные категории: взаимодействие на стороне клиента и взаимодействие на стороне сервера. Взаимодействие на стороне клиента включает в себя манипуляцию материалом, который обрабатывается локально на терминале конечного пользователя. В частности, модификация атрибута узла описания сцены, например, изменения положение объекта, делание его видимым или невидимым, изменение размера шрифта узла синтетического текста и т.д., может быть выполнено путем трансляции событий пользователя. Событием пользователя может быть нажатие клавиши мыши или команда, введенная с клавиатуры.
Другие формы взаимодействия на стороне клиента требуют поддержки со стороны синтаксиса описания сцены и должны быть специфицированы в стандарте. Использование структуры событий VRML предоставляет богатую модель, на основании которой разработчики могут создать вполне интерактивный материал.
Взаимодействие на стороне сервера включает в себя манипуляцию материалом на стороне отправителя в результате действий пользователя. Это, разумеется, требует наличия обратного канала.
3.3. Звук
MPEG-4 Аудио версия 2 является расширением MPEG-4 Аудио версия 1. В новой версии добавлены новые средства и функции, все прежние возможности и функции сохранены. Версия 2 MPEG-4 Аудио предоставляет следующие возможности:
Улучшенная устойчивость к ошибкам
Кодирование аудио, которое сочетает в себе высокое качество и малые задержки
Масштабируемость зерна изображения (масштабируемость разрешения вплоть до 1 кбит/с на канал)
Параметрическое аудио-кодирование для манипулирования звуком при низких скоростях.
Сжатие пауз в разговоре (CELP) для дальнейшего понижения потока данных при кодировании голоса.
Параметрическое кодирование речи, устойчивое к ошибкам.
Пространственная ориентация – возможность реконструировать звуковое окружение, используя метод моделирования.
Обратный канал, который полезен для настройки кодирования или масштабируемого воспроизведения в реальном времени.
Низкая избыточность транспортного механизма MPEG-4 для звука