Раздел: Документация
0 ... 22 23 24 25 26 27 28 ... 55 Транспортный стек - рекомендации Т.123 Приложения Т. 120 предполагают наличие базисных транспортных механизмов, способных обеспечить «надежную» доставку их протокольных блоков данных. Рис. 3.28 показывает взаимосвязи протокольных модулей семейства Т. 120 в многоточечной конференции. Рекомендации Т.123 [51] определяют наборы зависимых от сети протоколов для любого соединения между терминалами, между терминалами и MCU, между двумя MCU. Стандарт Т.123 задает транспортные профили для каждого из следующих типов сетей: -аналоговые телефонные сети общего пользования -сети ISDN -цифровые сети с коммутацией каналов -цифровые сети пакетной коммутации (Х.25) -сети TCP/IP -сети IPX/SPX. Терминал 1 Т. 126 Рабочая виртуальная доска Т. 124 Общее конференц-управление Т.122Т.125 Сервис групповых коммуникаций Т.123 Зависимые от сети компоненты Т. 124 Общее конференц-управление Т. 122 Т. 125 Сервис групповых коммуникаций Т.123 Т.123 Т.123 Терминал 2 Т. 126 Рабочая виртуальная доска Т. 124 Общее конференц-управление Т.122Т.125 Сервис групповых коммуникаций Зависимые от сети компоненты Терминал илиМСи Рис. 3.28. Взаимосвязь протокольных модулей в групповой Т. I 20-конференции На рис. 3.29 представлены транспортные профили, состветствующие уровню протоколов Т.123 для различных сетей. Из рисунка видно, что уровень Т.123 представляет обобщенный транспортный интерфейс и сервисы для вышележащего уровня MCS (Multipoint Communication Service). Транспортный уровень(4) Сетевой уровень(3) Канальный уровень(2) Физический уровень (1) Т. 122, Т. 125 Сервис групповых коммуникаций Х.224 класс 0 Нуль + SCr Q.922 I.430 или 1.431 Н.221, Н.224 ISDN Х.224 класс О Нуль + SCF Q.922 V.14, модем Х.224 класс 0 Х.25 Х.21 или X.21.bis PSDN Рис. 3.29. Транспортные профили Т. 120 - системь Протокол Т.123 поддерживает встроенные механизмы коррекции ошибок, что позволяет при разработке приложений не обращаться к аппаратным средствам для решения этой задачи. В конкретной компьютерной среде транспортный стек рекомендаций Т. 123 встраивается в средства системы, обеспечивающие интерфейс доступа к требуемой транспортной среде. Например, в Windows-среде стек Т. 123 может встраиваться в COMM.DRV для модемных соединений с ТФОП, в WINSOCK.DLL для TCP/IP и UDP и в NWIPXSPX.DLL для поддержки сетей Netware. Протокол и сервис групповых коммуникаций - Т. 122, Т.125. Рекомендации Т. 122 [52] определяет групповые сервисы, доступные для разработчиков, а Т.125 [53] специфицирует протоколы передачи данных групповых сообщений внутри и между доменами. Совместно они образуют коммуникационный механизм групповых документ-конференций. Служба групповых коммуникаций (Multipoint Communication Service - MCS) опирается на уровень стандарта Т. 123 в части доставки данных, но использование механизмов MCS полностью отделено от фактически используемого транспортного профиля. MCS является мощным инструментом решения широкого спектра задач при создании групповых приложений. Положения этих протоколов дают удобную абстракцию довольно сложного механизма многоадресной передачи данных. Механизмы, предоставляемые этими протоколами, реализуют: -логическое группирование терминалов в домены -объединение доменов в единую конференцию, используя разнообразные топологические схемы соединения модулей управления групповыми конференциями (MCU) -использование одного приложения одновременно в нескольких доменах -приоритетную передачу данных -управление дефицитными ресурсами и синхронизацию работы приложений. Рис. 3.30 иллюстрирует общую модель службы групповых соединений. Ее базисным компонентом является MCS-провайдер - активный элемент системы, который реализует непосредственную связь с нижележащим транспортным уровнем и расположенным выше уровнем приложений. MCS пользователь X MCS пользователь MCS провайдер М CS провайдер MCS соединения  MCS пользователь MCS провайдер MCS провайдер мси MCS провайдер MCS пользователь MCS пользователь Рис. 3.30. Модель службы группового сервиса Контроллер MCS-провайдеры организуются в упорядоченную древообразную структуру посредством MCS-соединений. MCS-провайдер может быть элементом приложения, выполняемого на терминале-клиенте или на MCU. Полное дерево MCS-соединений между MCS-провайдерами образует MCS-домен. Корневой узел дерева является главным провайдером домена и выполняет роль сервера ресурсов всего домена. Домен устанавливает некоторое подобие границ для обмена информацией между пользователями, подключенными к этому домену, равно как и для совместного использования ресурсов всего домена. Границы существующего домена могут быть расширены при подсоединении к нему удаленных терминалов. Рис. 3.31 и 3.32 иллюстрируют возможные варианты организации доменов. В домене, структура которого приведена на рис. 3.31, ряд MCS-провайдеров участвует в нескольких MCS-соединениях, а некоторые из MCS-провайдеров обеспечивают работу нескольких приложений. Рис. 3.32 показывает возможность одновременного участия одного MCS-провай-дера в нескольких доменах. Контроллер Приложение пользователя  Приложение пользователя Рис. 3.31. MCS - соединения в сети с пятью узлами  Рис. 3.32. Структура с множественными доменами Канал данных является ключевым элементом механизма обмена информацией в групповой конференции. Адресация каналов ограничивается пределами домена. Каждый пользователь в домене, т.е. каждое приложение, получающее сервис от MCS-провайдера, может присоединиться к определенному каналу (ассоциировать себя с этим каналом) для получения данных, направляемых в этот канал. Выбирая определенную комбинацию каналов, пользователи могут определять требуемую им информацию и игнорировать все то, что пересылается по каналам, не представляющим интереса для них. Существует четыре типа каналов. Групповые каналы используются для рассылки данных всем узлам или определенной группе клиентов домена. Это каналы открытого доступа и у них нет «владельца». Личные каналы обычно используются для передачи идентификаторов пользователей (user id) и служат для адресации двухточечных соединений внутри домена. Этот канал дает возможность информировать участников конференции о факте прекращения участия в ней конкретного участника. Закрытые каналы позволяют обеспечить контроль доступа для передачи и приема данных, пересылаемых по такому групповому каналу. Управление каналом осуществляется приложением, его создавшим. Такие каналы являются одним из механизллов формирования закрытых групп внутри конференции. Статические каналы существуют постоянно с момента формирования документа. MCS резервирует блок канальных идентификаторов (1...1000), которые присваиваются статическим каналам. Некоторые из статических каналов выполняют стандартные функции в протоколах, использующих MCS-сервис, и рекомендации Т. 120 жестко закрепляют их идентификаторы. I рупповые, личные и закрытые каналы являются динамическими (могут быть открыты в необходимом количестве и закрыты, когда их дальнейшее существование оказывается ненужным). Их идентификаторы (channel ids) находятся в интервале 1001 ...65535. Передача данных между участниками конференции становится возможной после формирования домена и создания необходимых каналов между приложениями. Существуют два вида сервиса пересылки данных - обычная пересылка и однородная. Обе они могут быть реализованы в режиме групповой адресации. Сервис обычной пересылки обеспечивает передачу данных по схемам «один ко многим», «многие к одному» и «многие ко многим». Во всех этих случаях данные к определенному терминалу поступают по кратчайшим и разным маршрутам вдоль дерева домена. Следовательно, картины, формирующиеся на мониторах участников конференции, могут отличаться. Сервис однородной передачи данных необходим в ситуации, когда данные, направляемые из разных (или одного) узлов, должны быть приняты всеми заинтересованными в них терминалами одновременно. Такая возможность обеспечивается посредством маршрутизации всех блоков данных к корню дерева (узел главного провайдера домена) и переправления их оттуда в одинаковой последовательности ко всем узлам приема, в том числе и к узлам-отправителям, если они ассоциированы с каналом назначения. Естественно, что «накладные расходы» такого сервиса больше. Проблема упорядочения приема данных может быть решена и без использования сервиса однородной передачи. Этому служит механизм назначения пересылаемым данным одного из четырех уровней приоритета. Такой механизм гарантирует, что упорядоченная последовательность данных, направленная от одного терминала в один канал и с одним уровнем приоритета, будет приниматься одинаково всеми 0 ... 22 23 24 25 26 27 28 ... 55
|
