ВУЗ:
Составители:
Рубрика:
ложения включают аудио- и видеоконференции, распространение живого видео (для немедленного вос-
произведения), разделяемые рабочие области, удалённую диагностику в медицине, компьютерную те-
лефонию, распределённое интерактивное моделирование, игры и мониторинг в реальном времени.
Использование TCP в качестве транспортного протокола для этих приложений невозможно по не-
скольким причинам. Во-первых, данный протокол позволяет установить соединение только между дву-
мя конечными точками и, следовательно, не подходит для многоадресной передачи. Он предусматрива-
ет повторную передачу потерянных сегментов, прибывающих в то время, когда приложение реального
времени уже их не ждёт. Кроме того, у TCP нет удобного механизма привязки информации о синхрони-
зации к сегментам, что также является требованием приложений реального времени.
Другой широко используемый протокол транспортного уровня – UDP не имеет первых двух ограни-
чений (соединение «точка–точка» и передача потерянных сегментов), но и он не предоставляет критиче-
ской информации о синхронизации. Таким образом, UDP сам по себе не имеет каких-либо инструментов
общего назначения для приложений реального времени.
Несмотря на то, что каждое приложение реального времени может обладать своими собственными
механизмами для поддержки передачи в реальном времени, они имеют много общих черт, что делает
определение единого протокола весьма желательным. Стандартный протокол такого рода – RTP, опре-
делённый в RFC 1889.
В типичной среде реального времени отправитель генерирует пакеты с постоянной скоростью. Они
отправляются им через одинаковые интервалы времени, проходят через сеть и принимаются получате-
лем, воспроизводящим данные в реальном времени по их получении.
Однако ввиду вариации задержки при передаче пакетов по сети они прибывают через нерегулярные
интервалы. Для компенсации этого эффекта поступающие пакеты буферизуются, придерживаются на не-
которое время и затем предоставляются с постоянной скоростью программному обеспечению, генери-
рующему вывод. Чтобы такая схема работала, каждый пакет получает отметку о времени – таким образом
получатель может воспроизвести поступающие данные с той же скоростью, что и отправитель.
RTP поддерживает передачу данных в реальном времени между несколькими участниками сеанса.
(Сеанс – это логическая связь между двумя и более пользователями RTP, поддерживаемая в течение
всего времени передачи данных. Процесс открытия сеанса выходит за рамки RTP.)
Хотя RTP может использоваться и для одноадресной передачи в реальном времени, его сила – в
поддержке многоадресной передачи. Для этого каждый блок данных RTP содержит идентификатор от-
правителя, указывающий, кто из участников генерирует данные. Блоки данных RTP содержат также от-
метку о времени, чтобы данные могли быть с правильными интервалами воспроизведены принимающей
стороной.
Кроме того, RTP определяет формат полезной нагрузки передаваемых данных. С этим напрямую
связана концепция синхронизации, за которую частично отвечает микшер – механизм трансляции RTP.
Принимая потоки пакетов RTP от одного или более источников, он комбинирует их и посылает новый
поток пакетов RTP одному или более получателям. Микшер может просто комбинировать данные, а
также изменять их формат.
Пример приложения для микшера – комбинирование нескольких источников звука. Например,
предположим, что часть систем данного аудиосеанса генерирует каждая свой собственный поток RTP.
Большую часть времени только один источник активен, хотя иногда одновременно «говорят» несколько
источников.
Если новая система хочет принять участие в сеансе, но её канал до сети не имеет достаточной точ-
ной ёмкости для поддержки всех потоков RTP, то микшер получает все эти потоки, объединяет их в
один и передаёт последний новому члену сеанса. При получении нескольких потоков микшер склады-
вает значения импульсно-кодовой модуляции. Заголовок RTP, генерируемый микшером, включает
идентификатор(-ы) отправителя(-ей), чьи данные присутствуют в пакете.
Более простое устройство создаёт один исходящий пакет RTP для каждого поступающего пакета
RTP. Этот механизм, называемый транслятором, может изменить формат данных в пакете или исполь-
зовать иной комплект низкоуровневых протоколов для передачи данных из одного домена в другой.
Например, потенциальный получатель может оказаться не в состоянии обрабатывать высокоскоростной
видеосигнал, используемый другими участниками сеанса. Тогда транслятор конвертирует видео в фор-
мат более низкого качества, требующий не такой высокой скорости передачи данных.
Каждый пакет RTP имеет основной заголовок, а также, возможно, дополнительные поля, специ-
фичные для приложения. Структуру основного заголовка иллюстрирует рис. 1.10. Первые 12 октетов
состоят из следующих полей:
Страницы
- « первая
- ‹ предыдущая
- …
- 27
- 28
- 29
- 30
- 31
- …
- следующая ›
- последняя »
