1. Этот протокол позволяет установить соединение только между двумя конечными точками, следовательно, он не подходит для многоадресной передачи.

2. ТСР предусматривает повторную передачу потерянных сегментов, прибывающих, когда приложение реального времени уже их не ждет.

3. ТСР не имеет удобного механизма привязки информации о синхронизации к сегментам = дополнительное требование приложений реального времени.

Другой широко используемый протокол транспортного уровня - UDP не имеет части ограничений ТСР, но и он не представляет критической информации о синхронизации.

Эту задачу и призван решить новый транспортный протокол реального времени - RTP ( Real-Time Transport Protocol), который гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах, т.е. данные могут быть воспроизведены в реальном времени.

Пакеты RTP содержат следующие поля: идентификатор отправителя, указывающий, кто из участников генерирует данные, отметки о времени генерирования пакета, чтобы данные могли быть воспроизведены принимающей стороной с правильными интервалами, информация о порядке передачи, а также информация о характере содержимого пакета, например, о типе кодировки видеоданных (MPEG, Indeo и др.). Наличие такой информации позволяет оценить величину начальной задержки и объема буфера передачи.

Протокол RTP используется только для передачи пользовательских данных - обычно многоадресной - всем участникам сеанса. Совместно с RTP работает протокол RTCP (Real-Time Transport Control Protocol). , основная задача которого состоит в обеспечении управления передачей RTP, RTCP использует тот же самый базовый транспортный протокол, что и RTP ( обычно UDP), но другой номер порта.

RTCP выполняет несколько функций:

1. Обеспечение и контроль качества услуг и обратная связь в случае перегрузки. Так как RTCP-пакеты являются много адресными, все участники сеанса могут оценить, насколько хороша работа и прием других участников. Сообщения отправителя позволяют получателям оценить скорость данных и качества передачи. Сообщения получателей содержат информацию о проблемах, с которыми они сталкиваются, включая утерю пакетов и избыточную неравномерность передачи.

Обратная связь с получателями важна также для диагностирования ошибок при распространении. Анализируя сообщения всех участников сеанса, администратор сети может определить, касается данная проблема одного участника или носит общий характер. Если приложение - отправитель приходит к выводу, что проблема характерна для системы в целом, например, по причине отказа одного из каналов связи, то оно может увеличить степень сжатия данных за счет снижения качества или вообще отказаться от передачи видео - это позволяет передавать данные по соединению низкой емкости.

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

3. Оценка размеров сеанса и масштабирование. Для обеспечения качества услуг и обратной связи с целью управления загруженностью, а также с целью идентификации отправителю все участники периодически посылают пакеты RTCP. Частота передачи этих пакетов снижается с ростом числа участников. При небольшом числе участников один пакет RTCP посылается максимум каждые 5 секунд.

ЛОГИЧЕСКАЯ СТРУКТУРА СЕТЕВОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

(ПРОТОКОЛ ОБМЕНА ДАННЫХ)

приложения

Формат UDP- пакета

Заголовок TCP – пакета ИНТЕРНЕТ

Рис. 3

Таким образом с протоколом сетевого уровня IP (Internet Prortocol) взаимодействуют два протокола транспортного уровня: TCP и UDP. TCP (transmission control protocol) обеспечивает надежную связь за счет мощных средств контроля ошибок при отправке пакетов и повторной отправки пакета в случае ошибки. UDP (user datagram protocol) такими средствами контроля над ошибками и повторной отправки пакета не обладает. Настольные системы видеоконференций, работающие по сетям Internet, используют протокол UDP для передачи аудио- и видеосигнала. Протокол TCP используется для передачи данных, таких, например, как данные с "настенной доски" или из разделяемых прикладных программ. При организации конференций по сетям Internet возникает одна проблема. Суть конференции в том, чтобы передавать изображение/голос/данные в общем случае в режиме широкого вещания. Однако протокол IP подразумевает связь "точка-точка". Чтобы преодолеть это препятствие, в 1989 г. было предложено расширение IP для поддержки широковещательных пакетов в Internet — RFC (Request for Comments). Благодаря RFC появилась возможность проводить конференции в Internet в режиме "широковещательной магистрали" Multicast Backbone (MBone), что означает возможность для одного участника конференции в Internet связываться одновременно с несколькими участниками. В режиме MBone группы хостов, поддерживающих широковещательный IP, связаны друг с другом по каналам чистого IP со связью "точка-точка". Данные к хостам группы передаются через широковещательный маршрутизатор. Это, как правило, рабочая станция, работающая в системе Unix. Для выбора оптимального пути от отправителя к получателю широковещательный маршрутизатор использует один из протоколов: DVMRP (Distance Vector Multicast Routing Protocol), MOSPF (Multicast Open Shortest Path First), PIM (Protocol Independent Multicast).

Необходимость передачи аудио- и видеоинформации по Internet привела к созданию нового транспортного протокола RTP (Real-time Transport Protocol). Его рабочая спецификация была предложена группой AVT (Audio/Video Transport working group) разработчиков средств передачи аудио/видеоинформации, входящей в организацию IETF (Internet Engineering Task Force). Протокол RTP отвечает за очередность, тайминг и качество аудио/видеоинформации, передаваемой в режиме "точка-точка" или "точка-многоточка". Большинство разработчиков систем MBone используют в своих системах RTP. Среди них такие как Communique! (InSoft), InPerson (Silicon Graphics), ShowMe (Sun Microsystems).