Раздел: Документация
0 ... 23 24 25 26 27 28 29 ... 55 приемными узлами. В таблице 3.10. приведено возможное распределение каналов, открытых неким приложением системы документ-конференции. Таблица 3.10.
 Рекомендации не накладывают никаких ограничений на размер блоков данных при их пересылке. Сегментирование данных осуществляется приложением, и после их пересылки только приложение несет ответственность за корректное восстановление сообщений. Серьезной проблемой организации работы распределенной группы является управление общими ресурсами домена и синхронизация работы~ „ . „v„ к ум~ ,лЗапрос маркера "X"Запрос маркера X распределенных приложении. Механизмом решения этих задач являются маркеры. Например, для того, чтобы гарантировать возможность использования Определенного ре-Выделение маркера "X"Отказ выделения маркера "X" сурса только одним приложением в течение необходимого ему временного интервала,n 0 00 v 1 I/Рис. 3.33. Схема выделение ресурса «X» этот ресурс снабжается маркером. Когда некий клиент хочет использовать специфический ресурс (ресурс «X»), он должен запросить себе соответствующий маркер. Распорядитель ресурса может удовлетворить этот запрос или отказать в зависимости от состояния маркера (рис. 3.33). Другим важным применением маркеров является синхронизация работы приложений. Например, предположим, что преподаватель ведет занятия с распределенной группой обучаемых и хочет получить ответы всех студентов на заданный им вопрос прежде, чем сообщить правильный ответ. Требуемая синхронизация может быть реализована посредством закрытия канала к каждому студенческому приложению специальным маркером (inhibit) после получения им запроса на ответ. Отсылка ответа снимает этот маркер и делает возможным доставку правильного ответа к этому узлу. MCS может поддерживать одновременно до 65535 маркеров. Для повышения устойчивости домена только главный провайдер домена имеет исключительное право оперирования маркерами. В рекомендациях Т. 122 определены шесть типов операций с маркерами: grab (захват), test (проверка), inhibit (запрет), please (удовлетворение запроса), give (передача), release (возврат в общедоступное состояние). 3.8.4. Служба и протокол унифицированного контроля конференции Рекомендации Т. 124 (Generic Conference Control-GCC) [54] определяют высокоуровневые процедуры, обеспечивающие управление конференцией, контроль функционирования мультимедиа терминалов и модулей групповых конференций (MCU). Рекомендации Т. 124 описывают функции установления и завершения конференции, управления списком участвующих терминалов, управления списком доступных приложений, координации действий участников конференции и т.п. Так же, как и рекомендации Т.122, Т.123, Т.125, стандарт Т. 124 является обязательным элементом всякой Т.120 системы. Рис. 3.34 дает пример распределения компонент служб контроля внутри домена. Каждый терминал или MCU содержит модуль GCC-провайдер, обеспечивающий сервис контроля и управления для контроллера узла и приложения. Каждый узел домена, участвующий в конференции, содержит модули уровней MCS, GCC, контроллер узла и одну или несколько протокольных компонент приложений, выполняющихся на этом узле. Взаимодействие между этими компонентами в рамках одного узла представлено на рис. 3.35. Точки доступа к сервису GCC (GCC SAP) и сервису MCS (МС SAP) обеспечиваются специальными примитивами, описанными в рекомендациях Т. 124. Следует иметь в виду, что настоящие рекомендации специфицируют процедуры и содержание только внешних коммуникаций, т.е. перечень элементарных операций и обмен данными, осуществляемые через МС SAP для целей контроля конференции. Внутреннее строение узла и процедуры внутреннего обмена информацией не нормируются в рекомендациях Т. 124. 
Протол. блоки приложений Рис. 3.34. Пример распределения GCC-компонент в домене Контроллер узла I Протокольные блоки приложений Точки доступа к GCC-сервису т GCC-провайдер -ч- Точки доступа к MCS-сервису MCS-провайдер Рис. 3.35. Модель взаимодействия служб группового сервиса на узле домена Важнейшей функцией GCC является ведение базы данных, отражающей состояние конференции (состав участников, перечень доступных ресурсов и т.п.). Один из узлов конференции, располагающей функциями MCU, является главным провайдером GCC. Информация о любых действиях и запросах от провайдеров GCC низлежащих узлов направляется к главному провайдеру для обновления информационной базы данных конференции. GCC предоставляет инструменты организации конференции. В момент ее создания формируется так называемый профиль конференции, включающий название конференции, форму доступа (по паролю, по приглашению или свободный). Расширение состава участников существующей конференции может быть инициировано или узлом, организующим конференцию, или любым узлом, желающим присоединиться к ней. Стандарт определяет возможности одновременного участия узла в нескольких конференциях. В рекомендациях Т. 124 определены и механизмы прекращения участия узла в конференции. Это может быть реализовано как по инициативе узла, так и по инициативе руководителя конференции. GCC определяет инструменты и форму регистрации приложений, выполняющихся на каждом узле конференции. Это позволяет всем узлам находить взаимно совместимые приложения. Более того, GCC дает возможность обмена информацией о возможностях приложений и выносит суждения о степени их совместимости. Эта функция очень важна для реализации взаимодействия между терминалами различных производителей. Еще одной важной функцией GCC является контроль использования MCS-ресурсов. Очевидно, что несколько приложений сразу могут запросить одни и те же ресурсы от MCS. В такой ситуации именно GCC предотвращает конфликты доступа к MCS-ресурсам (каналам, маркерам). GCC предоставляет механизм для назначения, идентификации и передачи прав председателя конференции. В момент создания конференции можно определить режим ее проведения с председателем или без него. Конкретное содержание функций и возможностей председателя определяется разработчиком приложения. GCC определяет некоторые базисные инструменты председателя, которые могут быть реализованы в конкретном приложении. Последний, например, может предусмотреть перечень операций, запрещенных для узлов без специального разрешения председателя. Контроллер узла т. 121 Обобщенный шаблон приложений 3.8.5. Рекомендации Т. 121. Обобщенный шаблон приложений Общая структура Т.120-системы (рис. 3.36) предусматривает возможность совместного использования приложений, реализующих как стандартные (Т. 126, Т.127), так и нестандартные протоколы. Хотя сами приложения, как правило, не являются объектом стандартизации, коммуникационные механизмы, которые ими используются, должны быть стандартными, что и является необходимым условием совместимости однородных приложений от различных производителей. Рекомендации Т.121 [55], определяя обобщенную модель Т.120-приложения, решают проблему совместимости пользовательских приложений. В соответствии с этой моделью, каждое пользовательское приложение должно содержать один или несколько протокольных блоков (рис. 3.35). Последние разделяются на два элемента: Приложение пользователя Унифициров. служба контроля конференции Т. 124 Модуль управления ресурсами приложения Модуль сервиса приложения Протокол и службы групповых коммуникаций т. 122, т.125 Рис. 3.36. Структура унифицированного шаблона приложения -модуль управления ресурсами (Application Resource Manager - ARM) -модуль сервиса приложений (Application Service Element - ASE).  Рис. 3.37. Пример формирования протокольных каналов для обмена данными однородных приложений в групповой конференции Модуль управления ресурсами ответственен за унифицированные функции контроля (GCC) и за доступ к MCS-ресурсам. Модуль сервиса приложений обеспечивает специфические функции приложения; например, определяемую стандартом Т.127 службу пересылки файлов или сервис обмена неподвижными изображениями по процедурами стандарта Т.126, или другие нестандартизированные функции документ-конференции. На рис. 3.37 представлен пример многотерминальной конференции. В ней однородные протокольные блоки разных приложений на разных терминалах осуществляют обмен информацией по общим, для каждого протокольного блока, каналам. Функции этого обмена обеспечиваются модулем управления ресурсами. Рекомендации Т.121 проблему совместимости приложений решают заданием унифицированного шаблона приложения (Generic Application Template - GAT), который содержит стандартизированный модуль управления ресурсами (ARM), но в который не включен модуль сервиса приложения (ASE). Функции, обеспечиваемые модулем GAT, являются общими для всякого Т. 120-приложения и включают в себя регистрацию приложения в базе 0 ... 23 24 25 26 27 28 29 ... 55
|
||||||||||||||||||||||||||||||||
