Синтетический звук
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. Этот язык используется для определения "оркестра", созданного из "инструментов" (загруженных в терминал потоком данных), которые формирует и обрабатывает управляющую информацию. Инструмент представляет собой маленькую сеть примитивов обработки сигналов, которые могут эмулировать некоторые специфические звуки, такие, которые могут производить настоящие акустические инструменты. Сеть обработки сигналов может быть реализована аппаратно или программно и включать как генерацию, так и обработку звуков, а также манипуляцию записанными ранее звуками.
MPEG-4 не стандартизует "единственный метод" синтеза, а скорее описывает путь описания методов синтеза. Любой сегодняшний или будущий метод синтеза звука может быть описан в SAOL, включая таблицу длин волн, FM, физическое моделирование и гранулярный синтез, а также непараметрические гибриды этих методов.
Управление синтезом выполняется путем включения "примитивов" (score) или "скриптов" в поток данных. Примитив представляет собой набор последовательных команд, которые включают различные инструменты в определенное время и добавляют их сигнал в общий музыкальный поток или формируют заданные звуковые эффекты. Описание примитива, записанное на языке SASL (Structured Audio Score Language), может использоваться для генерации новых звуков, а также включать дополнительную управляющую информацию для модификации существующих звуков. Это позволяет композитору осуществлять тонкое управление синтезированными звуками. Для процессов синтеза, которые не требуют такого тонкого контроля, для управления оркестром может также использоваться протокол MIDI.
Тщательный контроль в сочетании с описанием специализированных инструментов, позволяет генерировать звуки, начиная с простых аудио эффектов, таких как звуки шагов или закрытия двери, кончая естественными звуками, такими как шум дождя или музыка, исполняемая на определенном инструменте или синтетическая музыка с полным набором разнообразных эффектов.
Для терминалов с меньшей функциональностью, и для приложений, которые не требуют такого сложного синтеза, стандартизован также "формат волновой таблицы” (“wavetable bank format"). Используя этот формат, можно загрузить звуковые образцы для использования при синтезе, а также выполнить простую обработку, такую как фильтрация, реверберация, и ввод эффекта хора. В этом случае вычислительная сложность необходимого процесса декодирования может быть точно определена из наблюдения потока данных, что невозможно при использовании SAOL.
11. Приложение. Словарь и сокращения
| 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 |
/p>
Системы
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.
Системы Advanced BIFS
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, состоящих из отдельных объектов.
Совместимость с MIME
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". |
/p> Изображение, аудио и видео:
| - | На минимальном уровне предоставить возможность обрабатывать любой не узнанный субтип, как если бы он был "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) =
где N(B) – число всех элементарных исходов w, возможных при условии наступления события B, а N(АB) – число тех из них, которые приводят к осуществлению события А.
Если событие B ведет к обязательному осуществлению А: 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; пересечение
Пустые множества обозначаются 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 имеет непустое пересечение:
Гауссовы случайные процессы.
Действительная случайная величина x называется гауссовой, если ее характеристическая функция j =j (u) имеет вид
фигурирующие здесь параметры a и s2 имеют простой вероятностный смысл: a=Mx (среднее значение), s2 = Dx (средне-квадратичное отклонение). Соответствующее распределение вероятностей также называется гауссовым, его плотность имеет вид
Марковские случайные процессы.
Случайный процесс x =x(t) на множестве T действительной прямой в фазовом пространстве (E,B) называется марковским, если условные вероятности P(A|U(-Ґ,s) событий AО U(t,Ґ ) относительно s-алгебры U(-Ґ,s) таковы, что при s Јt с вероятностью 1
здесь U(u,v) означает s-алгебру порождаемую всевозможными событиями вида { x(t) О B}, t О[u,v]З T, BО B. Если параметр t интерпретировать как время, то описанное марковское свойство случайного процесса x =x (t) состоит в том, что поведение процесса после момента t при фиксированном состоянии x=x (t) не зависит от поведения процесса до момента t. Для любых событий А ОU
(-Ґ,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 существует предел
Pj=
где Qj – среднее время возвращения в состояние j в дискретные моменты t = 0, 1, 2, … .
Коэффициент эргодичности. Пусть x =x (t) – случайный марковский процесс в фазовом пространстве (E,B) с переходной функцией P(s,x,t,B). С вероятностью 1 имеет место равенство
b
(s,t) =
(-?, 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)
В случае непрерывного времени 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) =
а спектральная плотность f=f(l) удовлетворяет условию
(для дискретного 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(t)=0 при t>T.
Рассмотрим задачу линейной фильтрации при наличии на входе процесса x =x(t). Тогда x (t)= z (t) +h(t), где h =h(t) – полезный сигнал, а z(t) – независимый от него стационарный случайный процесс (шум). Линейное устройство должно быть выбрано так, чтобы процесс на входе
был по возможности близок к входному полезному сигналу 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. Процедуры регистрации
который разработал такие известные стандарты
2.5.1 Стандарт MPEG-4
|
Какое счастье, что вокруг Живут привольно и просторно Слова и запах, цвет и звук, Фактура, линия и форма |
|
|
И. Губерман |
Цифровое телевидение;
Интерактивные графические приложения (synthetic content);
Интерактивное мультимедиа World Wide Web.
Стандарт можно купить в ISO, связь через e-mail:sales@iso.ch. Программное обеспечение MPEG-4 может быть получено через сеть по адресу: www.iso.ch/ittf. Эти программы бесплатны, но это не означает, что они не защищены патентами. Смотри также http://mpeg.telecomitalialab.com/standards/mpeg-4/mpeg-4.htm.
сделали возможным интерактивное видео
2.5.2 Стандарт MPEG-7
Перевод http://mpeg.telecomitalialab.com/standards/mpeg-7/
MPEG-7 является стандартом ISO/IEC, разработанным MPEG (Moving Picture Experts Group), комитетом, который разработал стандарты MPEG-1, MPEG-2 и MPEG-4. Стандарты MpeG-1 и MPEG- 2 сделали возможным интерактивное видео на CD-ROM и цифровое телевидение. Стандарт MPEG-4 предоставляет стандартизованные технологические элементы, позволяющие интеграцию парадигм производства, рассылки и доступа к содержимому в области цифрового телевидения, интерактивной графики и интерактивного мультимедиа.
MPEG-7 формально называется “Мультимедиа-интерфейс для описания содержимого” (Multimedia Content Description Interface), он имеет целью стандартизовать описание мультимедийного материала, поддерживающего некоторый уровень интерпретации смысла информации, которая может быть передана для обработки ЭВМ. Стандарт MPEG-7 не ориентирован на какое-то конкретное приложение, он стандартизует некоторые элементы, которые рассчитаны на поддержку как можно более широкого круга приложений. Дополнительную информацию о MPEG-7 можно найти на базовой странице MPEG:
http://www.cselt.it/mpeg
а WEB-страница MPEG-7 (Industry Focus Group) размещена по адресу http://www.mpeg-7.com. Эти WEB-страницы содержат ссылки на информацию об MPEG, включая описание MPEG-7, многие общедоступные документы, списки "Frequently Asked Questions" и ссылки на WEB-страницы MPEG-7.
1. Введение
Огромное количество аудио-визуальной информации стало доступно в цифровой форме, в виде цифровых архивов, во всемирной паутине, в виде широковещательных потоков, а также в форме частных или профессиональных баз данных. Значение информации часто зависит оттого, насколько ее легко найти, извлечь, отфильтровать и управлять.
Тенденция очевидна. В ближайшие несколько лет, пользователи столкнутся с таким большим числом мультимедийных материалов, предоставляемых разными провайдерами, что эффективный доступ к этому почти бесконечному материалу представляется трудно вообразимым.
Несмотря на тот факт, что пользователи имеют увеличивающиеся ресурсы, управление ими становится все более сложной задачей, из-за их объема. Это касается как профессионалов, так и пользователей. Вопрос идентификации и управления материалами не ограничивается приложениями доступа к базам данных, таким как цифровые библиотеки, но распространяются в сферу выбора широковещательных каналов, мультимедийного редактирования и служб мультимедийных каталогов. Протокол MPEG-7 призван решить многие из этих проблем.
MPEG-7 является стандартом ISO/IEC, разработанным MPEG (Moving Picture Experts Group), комитетом, который разработал также стандарты MPEG-1 (1992), MPEG-2 (1995), и MPEG-4 (версия 1 в 1998 и версия 2 в 1999). Стандарты MPEG-1 и MPEG-2 позволили производить широко распространенные коммерческие продукты, такие как интерактивные CD, DVD, цифровое широковещательное аудио (DAB), цифровое телевидение, и многие другие коммерческие услуги. MPEG-4 является первым реальным мультимедийным стандартом для представления данных, позволяющим интерактивно работать с комбинациями натурального и синтетического материала, закодированного в виде объектов (он моделирует аудио-визуальные данные, как комбинацию таких объектов). MPEG-4 предоставляет стандартизованные технологические элементы, допускающие интеграцию производства, распределения и доступа к мультимедийному материалу. Это относится к интерактивному и мобильному мультимедиа, интерактивной графике и улучшенному цифровому телевидению.
Стандарт MPEG-7, формально назван “Multimedia Content Description Interface”. MPEG-7 предоставит широкий набор стандартизованных средств описания мультимедиа материала. В области действия MPEG-7 находятся как пользователи-люди, так и автоматические системы, выполняющие обработку аудио-визуального материала.
MPEG-7 предлагает полный набор аудиовизуальных средств описания, которые образуют базис для приложений, делая возможным высококачественный доступ к мультимедийному материалу, что предполагает хорошие решения для записи, идентификации материала, обеспечения прав собственности, и быстрой, эргономичной, точной целевой фильтрации, поиска.
Дополнительную информацию о MPEG-7 можно найти на WEB-сайте MPEG-7 http://drogo.cselt.it/mpeg/
и сайте MPEG-7 Industry Focus Group http://www.mpeg-7.com. Эти web- страницы содержат ссылки на ценную информацию о MPEG, включая материалы по MPEG-7, многие общедоступные документы, несколько списков ‘Frequently Asked Questions’ и ссылки на другие WEB-страницы MPEG-7.
1.1. Контекст MPEG-7
Доступно все больше и больше аудиовизуального материала из самых разных источников. Информация может быть представлена в различных медийных формах, таких как статические изображения, графика, 3D модели, звук, голос, видео. Аудиовизуальная информация играет важную роль в обществе, будучи записана на магнитную или фото пленку, или поступая в реальном масштабе времени от аудио или визуальных датчиков в аналоговой или цифровой форме. В то время как аудиовизуальная информация первоначально предназначалась для людей, в настоящее время все чаще такие данные генерируются и передаются и воспринимаются компьютерными системами. Это может быть, например, сопряжено с распознаванием голоса или изображения и медийным преобразованием (голос в текст, картинку в голос, голос в картинку, и т.д.). Другими сценариями являются извлечение информации (быстрый и эффективный поиск для различных типов мультимедийных документов, представляющих интерес для пользователя) и фильтрация потоков описаний аудиовизуального материала (чтобы получить только те элементы мультимедиа данных, которые удовлетворяют предпочтениям пользователя). Например, программа во время телепередачи запускает соответствующим образом программируемый VCR, чтобы записать эту программу, или сенсор изображения выдает предупреждение, когда происходит определенное событие. Автоматическое транскодирование может быть выполнено для строки символов, преобразовав ее в аудиоданные, или можно провести поиск в потоке аудио или видео данных. Во всех этих примерах, аудио-визуальная информация была приемлемым образом закодирована, что позволяет программе ЭВМ предпринять соответствующие действия.
Аудиовизуальные источники будут играть в перспективе все большую роль в нашей жизни, и будет расти необходимость обрабатывать такие данные. Это делает необходимым обработку видов аудиовизуальной информации, имеющей волновую форму, компрессированный формат (такой как MPEG-1 и MPEG-2) или даже объектно-ориентированный (такой как MPEG-4) формат. Необходимы формы презентации, которые позволяют некоторую степень интерпретации смысла информации. Эти формы могут быть переданы в, или доступны для прибора или программы ЭВМ. В примерах приведенных выше датчики изображения могут генерировать визуальные данные не в форме PCM (значения пикселей), а в форме объектов с ассоциированными физическими величинами и временной информацией. Эти объекты могут быть запомнены и обработаны с целью проверки, выполняются ли определенные условия. Видео записывающий прибор может получить описания аудиовизуальной информации, ассоциированной с программой, которая при выполнении заданных условий выдаст команду на запись, например, только новости за исключением спорта или запись фильма с автоматическим вырезанием вставок рекламы (согласитеь, об этом сегодня можно только мечтать).
MPEG-7 будет стандартом для описания мультимедийных данных, которые поддерживают определенные операционные требования. MPEG не стандартизует приложения. MPEG может, однако использовать приложения для понимания требований и развития технологий. Должно быть ясно, что требования, сформулированные в данном документе, получены из анализа широкого диапазона потенциальных приложений, которые могут использовать описания MPEG-7. MPEG-7 не ориентирован на какое-то конкретное приложение; скорее, элементы, которые стандартизует MPEG-7, будут поддерживать максимально широкий диапазон приложений.
1.2. Цель MPEG-7
В октябре 1996, группа MPEG начала разработку проблем, рассмотренных выше. Новым элементом семейства MPEG стал интерфейс описаний мультмедийного материала, называемый “Multimedia Content Description Interface” (или сокращенно MPEG-7), целью которого явилась стандартизация базовых технологий, позволяющих описание аудио-визуальных данных в рамках мультимедийной среды.
Аудиовизуальный материал MPEG-7 может включать в себя: статические изображения, графику, 3D модели, звук, голос, видео и композитную информацию о том, как эти элементы комбинируются при мультимедийной презентации. В особых случаях этих общих видов данных сюда может включаться выражения лица и частные характеристики личности.
Средства описаний MPEG-7 однако не зависят от способа кодирования и записи материала. Можно сформировать описание MPEG-7 аналогового фильма или картинки, которая напечатана на бумаге, точно также, как и цифрового материала.
MPEG-7, как и другие объекты семейства MPEG, предоставляют стандартное представление аудио-визуальных данных, удовлетворяющих определенным требованиям. Одной из функций стандарта MPEG-7 является обеспечение ссылок на определенные части мультимедийного материала. Например, дескриптор формы, используемый в MPEG-4, может оказаться полезным в контексте MPEG-7, точно также Это может относиться к полям вектора перемещения, используемым в MPEG-1 и MPEG-2.
В своих описаниях MPEG-7 допускает различную гранулярность, предлагая возможность существования различных уровней дискриминации. Хотя описание MPEG-7 не зависит от кодового представления материала, он может использовать преимущества, предоставляемые кодированным материалом MPEG-4. Если материал кодирован с использованием MPEG-4, который предоставляет средства кодирования аудио-визуального материала, в виде объектов, имеющих определенные связи во времени (синхронизация) и в пространстве (на сцене для видео или в комнате для аудио), будет возможно связать описания с элементами (объектами) в пределах сцены, такими как аудио и видео объекты.
Так как описательные характеристики должны иметь смысл в контексте приложения, они будут различными для разных приложений. Это подразумевает, что один и тот же материал может быть описан различным образом в зависимости от конкретного приложения. Возьмем в качестве примера визуальный материал: нижним уровнем абстракции будет описание, например, формы, размера, текстуры, цвета, движения (траектории) и позиции ("где на сцене может размещаться объект").
А для аудио: ключ, тональность, темп, вариации темпа, положение в звуковом пространстве. Высшим уровнем представления будет семантическая информация: "Это сцена с лающей коричневой собакой слева и голубым мячом, падающим справа, с фоновым звуком проезжающих авто". Могут существовать промежуточные уровни абстракции.
Уровень абстракции относится к способу выделения определенных характеристик: многие характеристики нижнего уровня могут быть выделены полностью автоматически, в то время как характеристики высокого уровня требуют большего взаимодействия с человеком.
Кроме описания материала, требуется также включить другие виды информации о мультимедийных данных:
Форма. Примером формы является используемая схема кодирования (например, JPEG, MPEG-2), или общий объем данных. Эта информация помогает определить, может ли материал быть воспринят пользователем.
Условия доступа к материалу. Это включает учет ограничений на использование материала, учитывающих авторские права и права собственности, а также цену.
Классификация. Это включает оценку происхождения материала и его классификацию по предопределенным категориям.
Связь сдругим важным материалом. Информация может помочь пользователю ускорить поиск.
Контекст. В случае записанного документального материала, очень важно знать обстоятельства записи (например, олимпийские игры 1996, финал of 200-метрового забега для мужчин с барьерами)
Во многих случаях будет желательно использовать для описания текстовые данные. Необходимо позаботиться о том, чтобы полезность описаний была независима по возможности от языка. Хорошим примером текстуального описания является указания авторов, названия фильма и пр.
Следовательно, средства MPEG-7 позволят формировать описания (т.e., наборы схем описания и соответствующих дескрипторов по желанию пользователя) материала, который может содержать:
Информацию, описывающую процессы создания и производства материала (директор, заголовок, короткометражный игровой фильм)
Информацию, относящуюся к использованию материала (указатели авторского права, история использования, расписание вещания)
Информация о характеристиках записи материала (формат записи, кодирование)
Структурная информация о пространственных, временных или пространственно-временных компонентах материала ( разрезы сцены, сегментация областей, отслеживание перемещения областей)
Информация о характеристиках материала нижнего уровня (цвета, текстуры, тембры звука, описание мелодии)
Концептуальная информация о реальном содержании материала (объекты и события, взаимодействие объектов)
Информация о том, как эффективно просматривать материал (конспекты, вариации, пространственные и частотные субдиапазоны, ...)
Информация о собрании объектов.
Информация о взаимодействии пользователя с материалом (предпочтения пользователя, история использования)
Все эти описания являются, конечно, эффективно закодированными для поиска, отбора и т.д.
Чтобы удовлетворить этому многообразию дополнительных описаний материала, MPEG-7 осуществляет описание материала с нескольких точек зрения. Наборы средств описаний, разработанные с учетом этих точек зрения, представляются в виде отдельных объектов. Однако они взаимосвязаны и могут комбинироваться множеством способов. В зависимости от приложения, некоторые будут присутствовать, а другие отсутствовать, а могут присутствовать лишь частично.
Описание, сформированное с помощью средств MPEG-7, будет ассоциировано с самим материалом, чтобы позволить быстрый и эффективный поиск и фильтрацию материала, представляющего интерес для пользователя.
Данные MPEG-7 могут физически размещаться вместе с ассоциированным AВ-материалом, в том же информационном потоке или в той же системе памяти, но описания могут также размещаться на другом конце света. Когда материал и его описания размещены не совместно, необходим механизм для соединения AВ-материала и его описаний MPEG-7; эти связи должны работать в обоих направлениях.
Тип материала и запрос могут не совпадать; например, визуальный материал может быть запрошен, используя визуальное содержимое, музыка, голос, и т.д. Согласование данных запроса и описания MPEG-7 выполняется поисковыми системами и агентами фильтрации.
MPEG- 7 относится ко многим различным приложениям в самых разных средах. Этот стандарт должен обеспечивать гибкую и масштабируемую схему описания аудио-визуальных данных. Следовательно, MPEG-7 не определяет монолитную систему описания материала, а предлагает набор методов и средств для различных подходов описания аудио-визуального материала. MPEG-7 сконструирован так, чтобы учесть все подходы, учитывающие требования основных стандартов, таких как, SMPTE Metadata Dictionary, Dublin Cилиe, EBU P/Meta, и TV Anytime. Эти стандарты ориентированы на специфические приложения и области применения, в то время как MPEG-7 пытается быть как можно более универсальным. MPEG-7 использует также схему XML в качестве языка выбора текстуального представления описания материала. Главными элементами стандарта MPEG-7 являются:
Дескрипторы (D). Представление характеристик, которые определяют синтаксис и семантику представления каждой из характеристик.
Схемы описания DS
(Description Scheme), которые специфицируют структуру и семантику взаимодействия между компонентами. Эти компоненты могут быть дескрипторами
и схемами описания.
Язык описания определений
DDL (Description Definition Language), позволяющий создавать новые схемы описания и, возможно, дескрипторы и обеспечивающий расширение и модификацию существующих схем описания,
Системные средства
служат для поддержки мультиплексирования описаний, синхронизации описаний и материала, механизмов передачи, кодовых представлений (как текстуальных, так и двоичных форматов) для эффективной записи и передачи, управления и защиты интеллектуальной собственности в описаниях MPEG-7.
1.3. Область действия стандарта
MPEG-7 относится к приложениям, которые могут осуществлять запись (или реализовать поточную передачу, например, производить широковещательную пересылку в Интернет), и могут работать как в реальном времени так и off-line. ‘Среда реального времени’ в данном контексте означает, что описание генерируется в процессе приема материала.
На Рисунок 1 показана блок-схема системы обработки данных MPEG-7. Чтобы полностью использовать возможности описаний MPEG-7, автоматическое извлечение характеристик (или ‘дескрипторов’) может оказаться особенно заметным. Ясно также, что автоматическое извлечение не всегда возможно. Как было указано выше, чем выше уровень абстракции, тем труднее автоматическое извлечение характеристик, и тем полезнее интерактивные средства.
Стандартные мультикастинг-адреса Интернет
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 |
/p>
Структура идентификаторов переменных в MIB
Рисунок 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
Структура кадров в GSM
Рисунок 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 ортогональны, то и
Когда сигналы от разных станций совпадают во времени и складываются, принимающая сторона легко может вычислить наличие соответствующей компоненты. Если компоненты суммарного сигнала 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.
Сжатие тишины CELP
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
Таблица анимации лица 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 |
Функциональные группы RMON
Таблица 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.
Коды Base
Таблица .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, для того чтобы разрешить кэширование таких данных.
Коды Base Код символа
Таблица 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 | (никаких ограничений на число соединений) |
Чтобы получить информацию о состоянии таблицы адресных преобразований, выдайте команду: SNMPI –a 193.124.224.33 dump at (процедуры с использование субкоманды dump требуют определенного времени для своего исполнения)
| 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 достаточно выдать команду:
SNMPI> dump ipaddrtable
| 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.148.166.222= 1 ( Все эти субсети используют для широковещательной адресации одни и те же биты).
| 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.148.166.222= 18024 (С точки зрения фрагментации и последующей сборки дейтограмм данные субсети эквивалентны).
| ipadentreasmmaxsize.192.168.1.1= | 18024 |
| ipadentreasmmaxsize.192.168.1.2= | 18024 |
| ipadentreasmmaxsize.193.124.224.33= | 18024 |
| ipadentreasmmaxsize.193.124.224.190= | 18024 |
Данная пропечатка совместно с приведенной для IFtable позволяет получить достаточно полную картину о данной конкретной локальной сети. Чтобы познакомиться с ARP таблицей, можно воспользоваться командой:
sun> arp -a
itepgw.itep.ru (193.124.224.33) at 0:0:c:2:3a:49
nb.itep.ru (193.124.224.60) at 0:80:ad:2:24:b7
и дополнить полученные данные с помощью SNMPI:
SNMPI> dump ipnettomediatable
SNMPI> ipnettomediaifindex.1.193.124.224.33= 1
ipnettomediaifindex.1.193.124.224.35= 1
ipnettomediaifindex.3.192.148.166.193= 3
ipnettomediaifindex.3.192.148.166.196= 3
ipnettomediaifindex.3.193.124.226.110= 3
ipnettomediaifindex.5.145.249.30.33= 5
ipnettomediaifindex.5.192.148.166.100= 5
ipnettomediaphysaddress.1.193.124.224.33= 0x00:00:0c:02:3a:49
ipnettomediaphysaddress.3.192.148.166.196= 0xaa:00:04:00:0c:04
ipnettomediaphysaddress.3.192.148.166.198= 0xaa:00:04:00:0e:04
ipnettomediaphysaddress.3.192.148.166.203= 0x00:00:01:00:54:62
.........................................
ipnettomediaphysaddress.5.145.249.30.33= 0x00:00:0c:02:69:7d
ipnettomediaphysaddress.5.192.148.166.100= 0x00:20:af:15:c1:61
ipnettomediaphysaddress.5.192.148.166.101= 0x08:00:09:42:0d:e8
ipnettomedianetaddress.1.193.124.224.33= 193.124.224.33
ipnettomedianetaddress.1.193.124.224.35= 193.124.224.35
ipnettomedianetaddress.3.192.148.166.193= 192.148.166.193
ipnettomedianetaddress.3.193.124.226.110= 193.124.226.110
ipnettomedianetaddress.5.145.249.30.33= 145.249.30.33
ipnettomediatype.1.193.124.224.33= other(1)
ipnettomediatype.1.193.124.224.35= dynamic(3)
ipnettomediatype.1.193.124.224.37= dynamic(3)
ipnettomediatype.3.192.148.166.195= dynamic(3)
ipnettomediatype.3.192.148.166.222= other(1)
ipnettomediatype.5.193.124.224.190= other(1)
ipnettomediatype.5.193.124.225.33= other(1)
ipnettomediatype.5.193.124.225.35= dynamic(3)
Синтаксис каждого объекта описывается в рамках ASN.1 и показывает побитовое представление объекта. Кодирование объекта характеризует то, как тип объекта отображается через его синтаксис и передается по телекоммуникационным каналам. Кодирование производится в соответствии с базовыми правилами кодирования asn.1. Все описания объектов базируются на типовых шаблонах и кодах asn.1 (см. RFC-1213). Формат шаблона показан ниже:
object (Объект):
Имя типа объекта с соответствующим ему идентификатором объекта (object identifier)
syntax (Синтаксис):
asn.1 описание синтаксиса типа объекта.
definition (Определение):
Текстовое описание типа объекта.
access (доступ):
Опции доступа.
status (состояние):
Статус типа объекта.
Маршруты также являются объектами mib. Согласно требованиям к mib, каждому маршруту в этой базе соответствует запись, схема которой приведена ниже на Рисунок 4.4.13.1.3:
Команды, выполняемые почтовой программой
Таблица 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 совместимы снизу вверх. При установлении связи между модемами используется наивысший протокол, поддерживаемый с обеих сторон канала.
Переменные AT-группы (attable, преобразование адресов)
Таблица 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 |
Стандарт на структуру управляющей информации (SMI) требует, чтобы все MIB-переменные были описаны и имели имена в соответствии с ASN.1 (abstract syntax notation 1, формализованный синтаксис). ASN.1 является формальным языком, который обладает двумя основными чертами:
используемая в документах нотация легко читаема и понимаема, а в компактном кодовом представлении информация может использоваться коммуникационными протоколами. В SMI не используется полный набор типов объектов, предусмотренный в ASN.1, разрешены только следующие типы примитивов: integer, octet string, object identifier и null. Практически в протоколе SNMP фигурируют следующие виды данных:
integer. Некоторые переменные объявляются целыми (integer) с указанием начального значения или с заданным допустимым диапазоном значений (в качестве примера можно привести номера UDP- или TCP-портов).
octet string (последовательность байтов). В соответствии с требованиями BER (basic encoding rules, ASN.1) последовательность октетов должна начинаться с числа байт в этой последовательности (от 0 до n).
object identifier (идентификатор объекта). Имя объекта, представляющее собой последовательность целых чисел, разделенных точками. Например, 192.148.167.129 или 1.3.6.1.2.1.5.
null. Указывает, что соответствующая переменная не имеет значения.
displaystring. Строка из 0 или более байт (но не более 255), которые представляют собой ASCII-символы. Представляет собой частный случай octet string.
physaddress. Последовательность октетов, характеризующая физический адрес объекта (6 байт для Ethernet). Частный случай object identifier.
Сетевой адрес. Допускается выбор семейства сетевых протоколов. В рамках ASN.1 этот тип описан как choice, он позволяет выбрать протокол из семейства протоколов. В настоящее время идентифицировано только семейство протоколов Интернет.
IP-адрес. Этот адрес используется для определения 32-разрядного Интернет-адреса. В нотации ASN.1 - это octet string.
time ticks (такты часов). Положительное целое число, которое используется для записи, например, времени последнего изменения параметров управляемого объекта, или времени последней актуализации базы данных.
Время измеряется в сотых долях секунды.
gauge (масштаб). Положительное целое число в диапазоне 0 - (232-1), которое может увеличиваться или уменьшаться. Если эта переменная достигнет величины 232-1, она будет оставаться неизменной до тех пор пока не будет обнулена командой сброс. Примером такой переменной может служить tcpcurresta, которая характеризует число TCP соединений, находящихся в состоянии established или close_wait.
counter (счетчик). Положительное целое число в диапазоне 0 - (232-1), которое может только увеличиваться, допуская переполнение.
sequence. Этот объект аналогичен структуре в языке Си.
Например, MIB определяет sequence с именем udpentry, содержащую информацию об активных UDP-узлах. В этой структуре содержится две записи:
1. UDPlocaladdress типа ipaddress, содержит местные IP-адреса.
2. UDPlocalport типа integer, содержит номера местных портов.
SEQUENCE OF. Описание вектора, все элементы которого имеют один и тот же тип. Элементы могут представлять собой простые объекты, например, типа целое. В этом случае мы имеем одномерный список. Но элементами вектора могут быть объекты типа SEQUENCE, тогда этот вектор описывает двумерный массив.
В Интернет MIB каждый объект должен иметь имя (object identifier), синтаксис и метод кодировки.
Стандарт ASN.1 определяет форму представления информации и имен. Имена переменных MIB соответствуют в свою очередь стандартам ISO и CCITT. Структура имен носит иерархический характер, отображенный на Рисунок 4.4.13.1.1.
Переменные IFtable (интерфейсы)
Таблица 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 |
Переменные IP-группы
Таблица 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
Переменные TCP-группы
Таблица 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 показан тип характеристики, которая реализована. Заметим, что в иерархическом дереве не нужно дублировать информацию формирования, использования и пр., так как предполагается, что дочерние сегменты наследуют эти характеристики.
Протоколы mnp
Таблица 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 | Включено питание модема. |
В современных ЭВМ имеется возможность совместить функции модема и факс-аппарата. Для решения этой задачи используются так называемые факс-модемы. Эти приборы работают в полудуплексном режиме. Ниже перечислены протоколы, используемые в этих аппаратах (кроме протоколов передачи данных факс-модемы поддерживают стандарты T.4 и T.30):
| 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 бит/с |
Для обеспечения работы факс-модема пригодны программы: Bitfax, Winfax, Quicklink или любая другая, поставляемая вместе с приобретенным вами модемом. Следует иметь в виду, что для пересылки через факс-модем традиционного документа, подготовленного на типографском бланке, написанного от руки и т.д., вам потребуется сканнер. В перспективе факс-технология будет вытеснена электронной почтой, которая эффективнее и, при необходимости, может обеспечить большую безопасность.
В настоящее время технология модемов продолжает развиваться, появились и активно внедряются кабельные модемы, много усилий тратится на развитие ADSL (см. http://www.adsl.com/general_tutorial.html (asymmetric digital subscriber line), SDSL (single line digital subscriber line), hdsl (high data rate digital subscriber line), VDSL (very high data rate digital subscriber line) и некоторых других технологий, связанных с передачей мультимедиа данных. (См. XDSL. atg’s communications & networking technology guide series. pairgain, copperoptics company; http://www.techguide.com/). Эти технологии предназначены для обеспечения широкополосного канала между провайдером и конечным пользователем (проблема последней мили). [Должен заметить, что миля мера иностранная и российским 1,853 км, если речь идет о телефонных кабелях, не соответствует. Провода у нас другого качества и наша миля как бы длиннее, если судить по искажениям сигнала и шумам]. Здесь используются три метода модуляции (2B1Q, CAP и DMT). ADSL позволяет приспособить обычные телефонные линии для мультимедийных приложений и для высокоскоростной передачи данных (до 6 Мбит/с).
Два ADSL-модема, соединенные скрученной парой проводов образуют три информационных канала: скоростной однонаправленный (нисходящий) канал (1,5-6,1 Мбит/с), среднескоростной дуплексный канал (16-640 Кбит/с) и POTS-канал (plain old telephone service). POTS сохраняет работоспособность даже при отказе ADSL. Каждый из этих каналов может мультиплексироваться, образуя каналы меньшего быстродействия. ADSL-модемы могут работать и с ATM-сетями, но следует учитывать их принципиальную асимметричность – передача в одном направлении и в другом имеет разную скорость. Для передачи данных в сети Интернет это не удобно. Но для транспортировки телевизионного сигнала такая схема представляется вполне эффективной.
Для провода длиной 5,5 км при диаметре сечения 0,5 мм (стандартные условия для isdn) пропускная способность составляет 1,5 - 2,0 Мбит/с (верхний край полосы пропускания около 1 МГц). При организации дуплексного канала весь частотный диапазон делится пополам и одна из частей используется для передачи данных в одном направлении, другая - в противоположном. Каждый из частотных диапазонов в свою очередь делится на части и для каждой из них используется техника эхо-подавления. Для POTS-канала выделяется 4 кГц в низкочастотной части диапазона.
HDSL представляет собой способ передачи потоков T1 или E1 по скрученным парам проводов с использованием улучшенной техники модуляции (для передачи 1,544-2,048 Мбит/с достаточно полосы 80-240 кГц). SDSL представляет собой версию HDSL с одной скрученной парой. Ниже в таблице 4.3.7.5 приведены сравнительные данные для различных систем передачи информации.
Разводка стандартных разъемов модема
Таблица 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 бит/с), дополнительные каналы для дистанционного управления. Такие каналы обладают повышенной устойчивостью, что позволяет сохранять целостность системы даже при временных отключеньях электропитания.
Системные переменные MIB
Таблица 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) | Местный номер порта приемника. |
Согласно этой иерархии переменные, соответствующие ICMP, должны иметь префикс (идентификатор) 1.3.6.1.2.1.5 или в символьном выражении iso.org.dod.internet.mgmt.mib.icmp. Если вы хотите узнать значение какой-то переменной, следует послать запрос, содержащий соответствующий префикс и суффикс, последний определяет имя конкретной переменной. Для простой переменной суффикс имеет вид .0. Ветвь структуры на Рисунок 4.4.13.1.1, завершающейся узлом Interfaces (2) имеет продолжение в виде ifTable(2) и ifEntry(1). Таким образом переменная ifInUcastPkts будет иметь представление 1.3.6.1.2.1.2.2.1.11.
Помимо стандартного набора переменных и таблиц MIB возможно использование индивидуальных расширений этой базы данных. Это можно продемонстрировать на примере MIB маршрутизаторов Cisco (Рисунок 4.4.13.1.2).
Свойства различных систем (модемов) передачи информации
Таблица 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. Эта программа осуществляет переадресацию сообщений от пользователя пользователю и от сервера серверу. Программа эта имеет большие возможности, но ее конфигурирование и использование представляет немалые трудности.
Внутренние команды почтовой программы UNIX
Таблица 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) | принять спецификацию, так как она есть, и поместить ее в перечень стандартов. |
Не существует необходимости для специальной процедуры регистрации транспортного кодирования IANA.
Все стандартные транспортные виды кодирования должны быть оформлены в виде RFC, таким образом, ответственность по информированию IANA об одобрении нового вида транспортного кодирования лежит на IESG.
4.4. Размещение списка зарегистрированных видов транспортного кодирования
Регистрационные материалы по всем стандартизованным видам транспортного кодирования доступны через анонимное FTP на сервере
ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-encodings/. Все зарегистрированные типы транспортного кодирования обязательно заносятся в списки документа "Assigned Numbers" [RFC-1700].
V. Критерии совместимости и примеры
Далее рассмотрено, какие части MIME должны поддерживаться MIME-совместимой программной реализацией.
Транспортный поток звука
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 – аудио поток с низкой избыточностью). Интерфейсный формат для транспортного уровня зависит от ниже лежащего коммуникационного уровня.
к ошибкам предоставляют улучшенные рабочие
10.2. Улучшения MPEG-4 аудио V.2
10.2.1. Устойчивость к ошибкам
Средства устойчивости к ошибкам предоставляют улучшенные рабочие характеристики для транспортных каналов, предрасположенных к ошибкам.
Улучшенную устойчивость к ошибкам для AAC предлагается набором средств сокрытия ошибок. Эти средства уменьшают воспринимаемое искажение декодированного аудио сигнала, которое вызвано повреждением бит информационного потока. Предлагаются следующие средства для улучшения устойчивости к ошибкам для нескольких частей AAC-кадра:
Средство виртуального кодового блокнота (VCB11)
Средство с обращаемыми кодовыми словами переменной длины RVLC (Reversible Variable Length Coding)
Средство изменения порядка кодовых слов Хафмана HCR (Huffman Codeword Reordering)
Возможности улучшения устойчивости к ошибкам для всех средств кодирования обеспечивается с помощью синтаксиса поля данных. Это позволяет применение продвинутых методик кодирования, которые могут быть адаптированы к специальным нуждам различных средств кодирования. Данный синтаксис полей данных обязателен для всех объектов версии 2.
Средство защиты от ошибок (EP tool) работает со всеми аудио объектами MPEG-4 версии 2, предоставляя гибкую возможность конфигурирования для широкого диапазона канальных условий. Главными особенностями средства EP являются следующие:
Обеспечение набора кодов для коррекции/детектирования ошибок с широким диапазоном масштабируемости по рабочим характеристикам и избыточности.
Обеспечение системы защиты от ошибок, которая работает как с кадрами фиксированной, так и переменной длины.
Обеспечение управления конфигурацией защиты от неравных ошибок UEP (Unequal Error Protection) с низкой избыточностью.
Алгоритмы кодирования MPEG-4 аудио версии 2 предоставляет классификацию всех полей потока согласно их чувствительности к ошибкам. На основе этого, поток данных делится на несколько классов, которые могут быть защищены раздельно с помощью инструмента EP, так что более чувствительные к ошибкам части окажутся защищены более тщательно.
Улучшенная модель синхронизации
4.2.3. Улучшенная модель синхронизации
Продвинутая модель синхронизации (обычно называемая ‘FlexTime’) поддерживает синхронизацию объектов различного происхождения с возможно разной временной шкалой. Модель FlexTime специфицирует временную привязку, используя гибкую модель с временными ограничениями. В этой модели, медиа-объекты могут быть связаны друг с другом в временном графе с использованием таких ограничений как "CoStart", "CoEnd", или "Meet". И, кроме того, для того чтобы обеспечить определенную гибкость и адаптацию к этим ограничениям, каждый объект может иметь адаптируемую длительность с определенными предпочтениями для растяжения и сжатия, которые могут быть применены.
Модель FlexTime базируется на так называемой метафоре "пружины". Пружина имеет три ограничения: минимальная длина, менее которой она не сжимается, максимальная длина, при которой она может оборваться, и оптимальная длина, при которой она остается ни сжатой, ни растянутой. Следуя модели пружины, временные воспроизводимые медиа-объекты могут рассматриваться как пружины, с набором длительностей воспроизведения, соответствующих этим трем ограничениям пружины. Оптимальная длительность воспроизведения (оптимальная длина пружины) может рассматриваться как предпочтительный выбор автора для длительности воспроизведения медиа-объекта. Участник, где возможно, поддерживает длительность воспроизведения настолько близко к оптимальному значению, насколько позволяет презентация, но может выбрать любую длительность между минимальной и максимальной, как это специфицировал автор. Заметим, что поскольку растяжение или сжатие длительности в непрерывных средах, например, для видео, подразумевает соответствующее замедление или ускорение воспроизведения, для дискретных сред, таких как статическое изображение, сжатие или растяжение сопряжено в основном с модификацией периода рэндеринга.
Улучшенная модель синхронизации (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, так что декодер может решить, может ли он участвовать в этой сессии.
При управлении конечным буферным пространством модель позволяет отправителю, например, передавать данные, не привязанные к реальному времени, досрочно, если имеется достаточно места в буфере со стороны приемника. Запомненные данные будут доступны в любое время, позволяя использовать для информации реального времени при необходимости большие ресурсы канала.
улучшает модель DMIF, чтобы
3.4.4. Управление информацией уровня Sync MPEG-4
V. 2 улучшает модель DMIF, чтобы позволить приложениям обмениваться прикладными данными со слоем DMIF. Это добавление было введено, чтобы сделать возможным в пределах модели обмен блоками протокольных данных уровня Sync. Это комбинация чисто медийных данных (PDU) и логической информации уровня Sync. Модель подтверждает, что в пределах существующего транспортного стека существуют средства, которые перекрываются с Sync-слоем систем MPEG-4. Это случай RTP и MPEG-2 элементарных потоков пакетов PES (Packetized Elementary Steams), а также MP4-атомов в файловом формате. Во всех таких случаях очевидной реализацией DMIF является преобразование информации уровня Sync, извлеченной из этих структур, а также из SL-PDU, в однородное логическое представление заголовка пакета уровня Sync. Как следствие, введены соответствующие параметры для DAI, с учетом обеспечения их семантической независимости от транспортного стека и приложения.
Управляющая база данных MIB
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 |
Устойчивое к ошибкам HVXC
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, они широко используются разработчиками средств противодействия ошибкам для видео.
Узел TemporalTransform
8.3.3.1. Узел TemporalTransform
TemporalTransform поддерживает синхронизацию узлов в пределах сцены с медиа потоком, или его сегментом, и поддерживает гибкое преобразование ко времени сцены. Этот группирующий узел может гибко поддерживать замедление, ускорение, замораживание или смещение временной шкалы сцены для рэндеринга узлов содержащихся в ней. Его дочернее поле может содержать список узлов типа SF3Dnode, а узел может влиять на замедление, ускорение, замораживание или смещение временной шкалы композитора, когда он осуществляет рэндеринг дочерних узлов, которые преобразованы этим узлом. Кроме того, этот узел имеет поле url, которое может ссылаться на элементарный поток или его сегмент и в этом случае, узел воздействует на временную шкалу потока, указанного в ссылке.
8.3.3.2. Узел TemporalGroup
Узел TemporalGroup специфицирует временное соотношение между заданным числом TemporalTransforms, чтобы выровнять временные шкалы узлов, в графе сцены. Временная настройка среды с целью удовлетворения ограничений и обеспечения гибкости осуществляется на уровне sync. TemporalGroup может рассматривать временные свойства его дочек и когда все они готовы, а временные ограничения выполнены, может быть дано разрешение на их воспроизведение.
Верификационное тестирование: проверка работы MPEG
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)
предоставляет пространственное масштабируемое кодирование статических объектов изображений (текстур), полезное для приложений, где нужны уровни масштабируемости, такие как установление соответствия между текстурой и объектами игр, а также работа с цифровыми фотокамерами высокого разрешения.
8. Визуальный профайл базовых анимированных 2-D текстур (Basic Animated 2- D Texture) предоставляет пространственную масштабируемоcть, SNR- масштабируемоcть, и анимацию, базирующуюся на сетках для статических объектов изображений (текстур), а также простую анимацию объектов лица.
9. Гибридный визуальный профайл комбинирует возможность декодировать масштабируемые объекты натурального видео произвольной формы (как в главном визуальном профайле) с возможностью декодировать несколько синтетических и гибридных объектов, включая анимационные статические объекты изображения. Он удобен для различных сложных мультимедиа приложений.
Версия 2 добавляет следующие профайлы для натурального видео:
10. Профайл ARTS (Advanced Real-Time Simple) предоставляет продвинутый метод кодирования прямоугольных видео объектов устойчивый к ошибкам, использующий обратный канал и улучшенную стабильность временного разрешения при минимальной задержке буферизации. Он удобен для кодирования в случае приложений реального времени, таких как видеотелефон, телеконференции и удаленное наблюдение.
11. Центральный масштабируемый профайл добавляет поддержку кодирования объектов произвольной формы с пространственным и временным масштабированием в центральный профайл. Главная особенность этого профайла является SNR, и пространственная и временная масштабируемость для областей и объектов, представляющих интерес. Он полезен для таких приложений как Интернет, мобильные сети и широковещание.
12. Профайл ACE (Advanced Coding Efficiency) улучшает эффективность кодирования для прямоугольных объектов и объектов произвольной формы. Он удобен для таких приложений как мобильный широковещательный прием, и другие приложения, где необходимо высокая эффективность кодирования.
Профайлы версии 2 для искусственного и синтетического/натурального гибридного визуального материала:
13. Продвинутый масштабируемый профайл текстур поддерживает декодирование текстур произвольной формы и статических изображений, включая масштабируемое кодирование формы, мозаичное заполнение и противостояние ошибкам.
Он полезен для приложений, требующих быстрого произвольного доступа, а также нескольких уровней масштабируемости и кодирования статических объектов произвольной формы. Примерами таких приложений могут служить просмотр статических изображений в Интернет, а также считывание через Интернет изображений, полученных из цифровых фотоаппаратов с высоким разрешением.
14. Продвинутый центральный профайл комбинирует возможность декодирования видео объектов произвольной формы (как в центральном визуальном профайле) с возможностью декодирования масштабируемых статических объектов произвольной формы (как в продвинутом масштабируемом профайле текстур.) Он удобен для различных мультимедийных приложений, таких как интерактивная передача потоков мультиимедиа через Интернет.
15. Профайл простой анимации лица и тела является супернабором профайла простой анимации лица с добавлением анимации тела.
В последующих версиях будут добавлены следующие профайлы:
16. Продвинутый простой профайл выглядит как простой, здесь он содержит только прямоугольные объекты, но он имеет несколько дополнительных средств, которые делают его более эффективным: B-кадры, компенсация перемещения ? пикселя и компенсация общего перемещения.
17. Масштабируемый профайл тонкой гранулярности допускает большое число масштабных уровней – до 8 – так что качество доставки можно легко адаптировать к условиям передачи и декодирования. Он может использоваться с простым или продвинутым простым в качестве базового уровня.
18. Простой студийный профайл является профайлом с очень высоким качеством для применения в приложениях студийного редактирования. Он работает только с I-кадрами, но он действительно поддерживает произвольные формы и большое число alpha-каналов. Возможная скорость передачи достигает 2 Гбит/c.
19. Центральный студийный профайл добавляет P-кадры к простому студийному варианту (Simple Studio), делая его более эффективным, но требующим более сложной реализации.
Восстановление данных
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, относится к типу клиентского приложения. Сначала все описания базы данных, которые могут быть извлечены из медиа приложения, декодируются и загружаются в память. Из медиа данных с помощью средства выборки может быть извлечено и описание запроса. С другой стороны запрос может быть загружен непосредственно из файла. После получения всех входных данных, запрос обрабатывается для всех элементов базы данных, а результирующие расстояния (значения отличия) используются для сортировки данных согласно уровню соответствия запросу. Наконец, сортированный список записывается в качестве медиа базы данных в файл.
Вычислительная модель DMIF
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.
Рисунок 2. Взаимодействие различных элементов
Рисунок 2. Взаимодействие различных элементов MPEG-7
На Рисунок 2 продемонстрирована масштабируемость рассмотренной концепции. Более того, там показано, что DDL предоставляет механизм построения схемы описания, которая в свою очередь образует основу для формирования описания (см. также Рисунок 3).
Взаимодействие с медийными объектами
1.5. Взаимодействие с медийными объектами
Пользователь видит сцену, которая сформирована согласно дизайну разработчика. В зависимости от степени свободы, предоставленной разработчиком, пользователь имеет возможность взаимодействовать со сценой. Пользователю могут быть разрешены следующие операции:
изменить точку наблюдения/слушания на сцене;
перемещать объекты по сцене;
вызывать последовательность событий путем нажатия кнопки мыши на определенных объектах, например, запуская или останавливая поток данных;
выбирать предпочтительный язык, когда такой выбор возможен;
Взаимодействие с пользователем
8.6. Взаимодействие с пользователем
MPEG-4 позволяет пользователю взаимодействие с отображаемым материалом. Это взаимодействие может быть разделено на две главные категории: взаимодействие на стороне клиента и взаимодействие на стороне сервера. Взаимодействие на стороне клиента включает в себя манипуляцию материалом, который обрабатывается локально на терминале конечного пользователя. В частности, модификация атрибута узла описания сцены, например, изменения положение объекта, делание его видимым или невидимым, изменение размера шрифта узла синтетического текста и т.д., может быть выполнено путем трансляции событий пользователя. Событием пользователя может быть нажатие клавиши мыши или команда, введенная с клавиатуры.
Другие формы взаимодействия на стороне клиента требуют поддержки со стороны синтаксиса описания сцены и должны быть специфицированы в стандарте. Использование структуры событий VRML предоставляет богатую модель, на основании которой разработчики могут создать вполне интерактивный материал.
Взаимодействие на стороне сервера включает в себя манипуляцию материалом на стороне отправителя в результате действий пользователя. Это, разумеется, требует наличия обратного канала.
Звук
3.3. Звук
MPEG-4 Аудио версия 2 является расширением MPEG-4 Аудио версия 1. В новой версии добавлены новые средства и функции, все прежние возможности и функции сохранены. Версия 2 MPEG-4 Аудио предоставляет следующие возможности:
Улучшенная устойчивость к ошибкам
Кодирование аудио, которое сочетает в себе высокое качество и малые задержки
Масштабируемость зерна изображения (масштабируемость разрешения вплоть до 1 кбит/с на канал)
Параметрическое аудио-кодирование для манипулирования звуком при низких скоростях.
Сжатие пауз в разговоре (CELP) для дальнейшего понижения потока данных при кодировании голоса.
Параметрическое кодирование речи, устойчивое к ошибкам.
Пространственная ориентация – возможность реконструировать звуковое окружение, используя метод моделирования.
Обратный канал, который полезен для настройки кодирования или масштабируемого воспроизведения в реальном времени.
Низкая избыточность транспортного механизма MPEG-4 для звука
При кодировании 2- канального материала при 128 кбит/с как AAC главного профайла так и AAC профайла низкой сложности были оценены как имеющие "неотличимое качество" (относительно оригинала) согласно определению EBU.
Два масштабируемых кодировщика, CELP-база с улучшение AAC, и TwinVQ база с улучшением AAC, работают лучше чем AAC "multicast", работающий при скорости передачи уровня улучшения, но не так хороши как кодировщик AAC, работающий при полной скорости передачи.
Широкополосное кодирующее средство CELP демонстрирует прекрасные характеристики только для голоса.
Побитовое арифметическое кодирование (BSAC) предоставляет весьма малые шаги масштабирования. На верху диапазона масштабирования это кодирование не имеет штрафных балов по отношению к AAC, однако в нижней части диапазона оно уступает односкоростной AAC.
Узкополосный CELP, TwinVQ и индивидуальные гармонические линии и шум (HILN) все могут обеспечить очень высокое сжатие сигнала.
Средства противодействия ошибкам (ER) обеспечивают эквивалентно хорошую устойчивость к ошибкам в широком диапазоне условий канальных ошибок, и делают это с достаточно малой избыточностью по скорости передачи.
