ВУЗ:
Составители:
Рубрика:
Time Transport Control Protocol, RTCP) работает с несколькими адресатами для обеспечения обратной
связи с отправителями данных RTP и другими участниками сеанса.
RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но дру-
гой номер порта. Каждый участник сеанса периодически посылает RTCP-пакет всем остальным участ-
никам сеанса. RFC 1889 описывает три функции, выполняемые RTCP.
Первая функция состоит в обеспечении качества услуг и обратной связи в случае перегрузки. По-
скольку RTCP-пакеты являются многоадресными, то все участники сеанса могут оценить, насколько
хороши работа и приём других участников. Сообщения отправителя позволяют получателям оценить
скорость данных и качество передачи. Сообщения получателей содержат информацию о проблемах, с
которыми они сталкиваются, включая утерю пакетов и избыточную неравномерность передачи. Напри-
мер, скорость передачи для аудио- и видеоприложения может быть снижена, если линия не обеспечива-
ет желаемого качества услуг при данной скорости передачи.
Обратная связь с получателями важна также для диагностирования ошибок при распространении.
Анализируя сообщения всех участников сеанса, администратор сети может определить, касается ли
данная проблема одного участника или носит общий характер.
Вторая основная функция RTCP – идентификация отправителя. Пакеты RTCP содержат стандарт-
ное текстовое описание отправителя. Они предоставляют больше информации об отправителе пакетов
данных, чем случайным образом выбранный идентификатор источника синхронизации. Кроме того, они
помогают пользователю идентифицировать потоки, относящиеся к различным сеансам. Так, они дают
пользователю возможность определить, что одновременно открыты отдельные сеансы для аудио и ви-
део.
Третья функция состоит в оценке размеров сеанса и масштабировании. Для обеспечения качества
услуг и обратной связи с целью управления загруженностью, а также с целью идентификации отправи-
теля, все участники периодически посылают пакеты RTCP. Частота передачи этих пакетов снижается с
ростом числа участников.
При небольшом числе участников один пакет RTCP посылается максимум каждые пять секунд.
RFC 1889 г. описывает алгоритм, согласно которому участники ограничивают частоту RTCP-пакетов в
зависимости от общего числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5 % от
общего трафика сеанса.
Назначение любой сети состоит в доставке данных получателем с гарантированным качеством услуг,
включающих пропускную способность, задержку и допустимый предел вариации задержки. С ростом
числа пользователей и приложений обеспечить качество услуг становится всё труднее.
Всего лишь реагировать на перегрузку – уже недостаточно. Необходим инструмент, с помощью ко-
торого перегрузок можно было бы избежать вообще, т.е. сделать так, чтобы приложения могли резерви-
ровать сетевые ресурсы в соответствии с требуемым качеством услуг.
Превентивные меры полезны как при одноадресной, так и при многоадресной передаче. При одно-
адресной передаче два приложения договариваются о конкретном уровне качества услуг для данного
сеанса. Если сеть сильно загружена, то она может оказаться не в состоянии предоставить услуги необ-
ходимого качества. В этой ситуации приложениям придётся отложить сеанс до лучших времен или по-
пробовать снизить требования к качеству услуг, если это возможно.
Решение в данном случае состоит в резервировании одноадресными приложениями ресурсов для
обеспечения требуемого уровня услуг. Тогда маршрутизаторы на предполагаемом пути выделяют ре-
сурсы (например, место в очереди и часть ёмкости исходящей линии). Если маршрутизатор не имеет
возможности выделить ресурсы вследствие ранее взятых на себя обязательств, то он извещает об этом
приложение. При этом приложение может попытаться инициировать другой сеанс с меньшими требо-
ваниями к качеству услуг или перенести его на более поздний срок.
Многоадресная рассылка ставит гораздо более сложные задачи по резервированию ресурсов. Она ведёт
к генерации огромных объёмов сетевого трафика – в случае, например, таких приложений, как видео, или
при наличии большой и рассредоточенной группы получателей. Однако трафик от источника многоадрес-
ной рассылки может быть в принципе значительно снижен.
Для этого есть два основания. Во-первых, некоторые члены группы могут не нуждаться в доставке
данных от конкретного источника в определённый период времени. Так, члены одной группы могут по-
лучать информацию одновременно по двум каналам (от двух источников), но при этом получатель может
быть заинтересован в приёме только одного канала.
Во-вторых, некоторые члены группы в состоянии обрабатывать только часть передаваемой отпра-
вителем информации. Например, видеопоток может состоять из двух компонентов: один с низким каче-
ством картинки, а другой – с высоким. Такой формат имеет ряд алгоритмов сжатия видео: они генери-
Страницы
- « первая
- ‹ предыдущая
- …
- 29
- 30
- 31
- 32
- 33
- …
- следующая ›
- последняя »
