Проблема передачи мультимедийного трафика через сеть Интернет, не предоставляющей на сегодня никаких гарантий по доставке пакетов и их задержке, является нетривиальной задачей. Как было отмечено ранее, большинство современных мультимедийных приложений используют на транспортном уровне протокол UDP, поэтому утверждение остается справедливым. Контроль качества предоставляемой услуги необходим уже сегодня, в первую очередь, для улучшения ее функционирования. Например, в программном обеспечении клиента RealOne и сервера Helix Server фирмы RealNetworks уже реализованы функции автоматического адаптивного переключения качества Передаваемого «потокового» видео и «потокового» аудио в зависимости от пропускной способности «из-конца-в-конец» канала между сервером и клиентом. Заметим, что для этого на стороне сервера должны быть сохранены соответствующие «потоковые» файлы с различной скоростью кодирования.

ремонт сололифт грундфос своими руками.

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

На сегодня существует достаточное количество механизмов и алгоритмов, реализуемых на прикладном уровне и позволяющих как получать исчерпывающую статистику о параметрах используемого канала (естественно, не учитывая канальный уровень, где могут функционировать достаточно продвинутые алгоритмы борьбы с ошибками, как например, в беспроводной локальной сети WLAN 802.11b [WLAN]), так и повышать достоверность доставки информации. Статистика собирается при помощи помещения в заголовки сегменты прикладного Уровня таких дополнительных полей, как номер сегмента и «временная метка» (timestamp). Как правило, алгоритмы повышения достоверности доставки информации строятся на принципах внесения избыточности и перестановки в последовательности посылаемых сегментов данных прикладного уровня. Среди наиболее известных алгоритмов стоит отметить fec и interleaving [Perkins98, RosenbergOOj.

Разнообразие корпоративных протоколов, реализованных на прикладном уровне и, как следствие, невозможность их совместного функционирования, привело к решению стандартизировать и использовать один протокол, который был назван «протокол реального времени» (Real-Time Protocol, далее - RTP) [RFC 1889]. RTP может быть использован для передачи информации в таких распространенных форматах, как PCM, GSM, MP3, MPEG, Н.263 и, конечно же, в любом корпоративном формате (proprietary format). Очевидно, что использование стандартизированного протокола RTP вместо «корпоративного» выгодно для разработчиков приложений - при корректной реализации RTP-приложение имеет возможность функционировать с приложениями других разработчиков. Например, приложение Интернет-телефона одного разработчика будет иметь возможность совместно функционировать с приложением Интернет-телефона другого, что особенно важно при использовании на оконечных хостах различных ОС.

Самая свежая и полная информация о протоколе RTP может быть найдена в Интернете по адресуhttp://www.cs.columbia.edu/~hgs/rtp.

Далее в этой главе рассмотрим подробнее протокол RTP и используемый совместно с ним управляющий протокол RTCP.

⇐Механизм tcp ecn | Управление трафиком и качество обслужевания в сети | Общие сведения о протоколе rtp⇒