О программной реализации.

 

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

Хорошо известно, что реализация функций взаимосвязи весьма ресурсоемка. Определенное представление об этом можно было составить из уже усвоенного материала. Поэтому для выполнения связных процедур и для обработки обычных (прикладных) задач чаще всего используют отдельные подсистемы. Как правило, полная подсистема связи - это некоторый отдельный конструктив. В нем объединены: локальный процессор связи; память, имеющая объем, достаточный для хранения программных реализаций протоколов и участвующих в обработке данных; схемы, необходимые для реализации физического интерфейса с сетью. Данные включают в себя информацию о (локальном) состоянии протокола каждого из уровней и сообщения, передаваемые между уровнями.

Прикладные процессы пользователей выполняются на главной (host) системе. Взаимодействие главной системы и ее подсистемы связи опирается на программное обеспечение межпроцессорных связей, имеющееся в обеих системах. Синхронизация обмена данными между ними обеспечивается системой прерываний.

Программные реализации протоколов смежных уровней должны быть автономны в том же смысле, что и сами эти уровни, ибо в противном случае будут утрачены все преимущества многоуровневой архитектуры. Поэтому полная подсистема связи реализуется в виде пакета модулей задач (процессов), по одному на каждый уровень, с добавленными задачами для выполнения (локальных) функций управления и обработки прерываний таймера. Задачи взаимодействуют друг с другом с помощью набора очередей или почтовых ящиков, как это показано на рис.3.1.1, используемая дисциплина - FIFO (первым пришел - первым обслужен). Межзадачное взаимодействие осуществляется через локальное ядро, функционирующее в режиме реального времени. Это же ядро производит планирование задач и обработку прерываний, поступающих от таймеров.

 

Смежные уровни взаимодействуют друг с другом с помощью примитивов. Это взаимодействие имеет атомарный (неделимый) характер, что проявляется двояким образом. С одной стороны - сами примитивы - это первичные, неделимые элементы описания сервиса. С другой - ход обработки протокольным автоматов одного из них не может быть прерван обработкой другого, несмотря на асинхронность моментов их появления. Для обеспечения атомарности обработки каждого входного события (принятия примитива к обработке) прочие локальные события передаются протокольному объекту тем же способом, что и те, которые поступают сверху и снизу от смежных уровней. С таким подходом мы встретимся также при рассмотрении организации управления ВОС и услуг СЭПС информационных служб управления с доступом их примитивов непосредственно на нужный уровень. Здесь - несколько позже - речь пойдет о примитивах таймера.

Каждый примитив службы совместно со связанными с ним параметрами формируется в буфере памяти, называемом блоком управления событиями (БУС). Форма представления этих параметров локальна и соответствует языку реализации протокольных объектов (задачи в целом).

Как правило, число и тип параметров зависят от примитива, однако с каждым протокольным объектом связывают единую структуру (БУС) символьных данных. При этом в заголовке каждого БУС имеется поле типа примитива, за ним следует поле всех возможных параметров, связываемых с полным набором примитивов одного уровня. При передаче примитивов между уровнями посылающая задача указывает тип передаваемого примитива в заголовке БУС, а получающая задача использует это поле, чтобы определить ту конкретную процедуру выходного события, которая должна быть инициирована в данном случае. Эта процедура выделяет лишь те параметры, которые касаются ее, т.е. лишь те, которым присвоены содержательные значения.

Структура типичного БУС приведена на рис.3.1.2. Этот БУС относится к транспортному уровню, т.е. используется при взаимодействии между сеансовым и транспортным уровнями для всех транспортных примитивов запроса, индикации, ответа и подтверждения. Полный БУС имеет структуру записи (record), а переменной ТипСобытия присваивается тип примитива службы. Об использовании поля УказательНаБфДП и связанного с ним ДлинаБфДП см. далее. Поля вызываемых и вызывающих СнТДС, ТТДС и СтТДС применяются в примитивах Т-СОЕДИНЕНИЕ, а поля ИдПриемника и ИдИсточника - в последующих примитивах Т-ДАННЫЕ для установления соответствия между транспортным соединением и данными пользователя, связанными с примитивами.

 

 

Чтобы передавать примитивы службы между уровнями (задачами), инициирующая задача формирует для локального ядра примитив взаимодействия задач, выдавая в качестве параметра указатель адреса БУС. В результате этого ядро помещает указатель в конец соответствующей межуровневой очереди. Задача в начале работы опрашивает все свои очереди между ее и выше- и нижележащим уровнем, а также очереди с задачами управления и таймера в отношении наличия БУС, ожидающего обработки. Если таковой имеется, то задача считывает указатель из начала соответствующей очереди и приступает к обработке входного события. В результате, как правило, формируется БДП и строится должным образом форматированное сообщение, которое затем помещается в одну из выходных очередей задачи.

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

Первый подход привлекателен в силу своей простоты, однако его применение грозит либо значительным снижением эффективности обработки, либо малообозримыми затруднениями в случае попыток разобраться с причинами, вызвавшими временную (возможно, надолго) блокировку активной ТДС - особенно в случае, когда нужно передавать срочные данные. Задержка может быть обусловлена, например, регулировкой потока, а посылка срочных данных - задействованием механизма обработки отказов. В итоге на практике с каждой ТДС ассоциируется свой набор очередей. Если теперь какая-либо активная ТДС окажется временно закрытой, то следует просто отложить обработку элементов в соответствующей очереди, пока не будет снят временный запрет. Поток сообщений через другие активные ТДС не будет задержан.

С каждым примитивом бывают связаны данные пользователя, которые, как правило, являются конкатенацией УИП, относящихся к вышележащим уровням. Протокольный объект, получив примитив службы (БУС), использует параметры, связанные с примитивом, а также информацию о текущем состоянии протокола, связанную с данным соединением, чтобы сформировать УИП данного уровня. Затем эта УИП объединяется с данными пользователя, связанными с поступившим примитивом, образуя БДП данного уровня. Именно этот БДП передается нижележащему уровню в поле данных пользователя требующегося в данном случае примитива.

Данные пользователя, связанные с примитивом, хранятся в т.н. буфере данных пользователя (БфДП). Именно в БфДП хранятся накопленные УИП (БДП) каждого из вышележащих уровней, так что содержимое именно БфДП передается физическим уровнем. Как известно, УИП каждого уровня определяется так, чтобы в любой системе она могла быть однозначно проинтерпретирована, так что вне зависимости от того, что из себя представляют, как структуры данных, БДП, они имеют в конечном счете форму цепочки октетов. Другими словами, каждый БфДП описывается как одномерный массив (array) октетов. Поле УказательНаБфДП каждого БУС является указателем адреса начала БфДП, содержащего данные пользователя, что связаны с примитивом. Величина ДлинаБфДП используется в качестве индикатора числа октетов, содержащихся в данный момент в буфере. Каждый раз, когда очередной уровень присоединяет свою УИП к уже имеющемуся содержимому буфера, значение ДлинаБфДП увеличивается на требуемую величину. После поступления БфДП на физический уровень полученное в конечном счете число октетов пересылается из БфДП удаленной системе.

Структура отдельного протокола уровня в контексте всего пакета подсистемы связи изображена на рис.3.1.3.

 

Для обеспечения доступности на каждом уровне все БУС и все связанные с ними БфДП объявляются глобальными структурами. Обычно весь пул из БфДП для каждого уровня формируется при начальной инициализации системы и при этом указатели буферов объединяются в список. Каждый раз, когда появляется потребность в новом буфере, из списка извлекается указатель на очередной свободный буфер; каждый раз, когда буфер перестает быть нужным, указатель в список возвращается.

Для того, чтобы уровень мог обрабатывать несколько запросов на службу параллельно, с каждой активной ТДС должен ассоциироваться отдельный набор автоматных переменных (массив ТаблицаСостоянийСобытий нужен в единственном экземпляре). Для простоты на рис.3.1.3 показан только один набор. Для примера был выбран транспортный уровень, так что можно сопоставить фрагменты его описаний в форме на рис.3.1.3 и в представленной ранее форме конечного автомата.

Планирование задач осуществляется ядром реального времени. Если в данный момент некоторая задача (уровень) бездействует - ждет наступления входного события, то после того, как указатель на БУС помещается в одну из входных очередей задачи, ядро автоматически ее запускает. Сначала тип события из БУС (тип примитива) присваивается переменной ТипСобытия, которая в сочетании с переменной ТекущееСостояние используется для входа в массив ТаблицаСостояний событий. Выбранная таким образом клетка массива определяет подлежащую запуску процедуру выходного события и новое ТекущееСостояние. Если же в клетке содержатся предикаты, то определяется список альтернативных комбинаций “выходное событие/новое состояние”. Предикаты устанавливаются/сбрасываются либо в процессе обработки отдельных событий, либо в результате обращения к специально написанным булевским функциям.

Прикладной процесс (ПП) пользователя выполняется на главной системе. Он получает доступ к службам распределенной информации с помощью полной подсистемы связи, применяя для этого имеющийся комплект примитивов, который соответствует элементу пользователя (ЭП). Подробнее о таких примитивах (примитивах пользователя) речь пойдет несколько позже. ЭП - это пакет библиотечных процедур, которые подключаются к ПП до начала его работы в целях взаимного преобразования примитивов, применяемых в среде реальных систем (СРС) и примитивов, связанных с конкретным СЭПС в среде ВОС (СВОС).

Чтобы установить связь с определенным СЭПС, ЭП сначала получает свободный БУС, относящийся к данному СЭПС. Обычно это указатель адреса начала буфера в совместно используемой памяти. Затем ЭП записывает в БУС необходимые параметры, связанные с примитивом, после чего инициирует передачу указателя адреса БУС выбранному СЭПС с помощью программного обеспечения межпроцессорных связей. Любые данные пользователя, связанный с примитивом, заносятся в БфДП. Указатель адреса этого БфДП записывается в БУС, куда заносится также значение объема данных, содержащихся в БфДП. Получив БУС, выбранный СЭПС действует далее уже описанным в целом образом.

Ясно, что объем данных пользователя, содержащийся в БфДП, по мере прохождения вниз сквозь все уровни будет изменяться и в конце может составить величину от примерно нескольких сотен октетов, если пересылается только УИП, до нескольких тысяч октетов, если передается, например, (по частям) содержимое файла. Длина БфДП обычно фиксирована, так что в подобных случаях для обработки составных блоков используются списки буферов. Если очередной БфДП заполняется, то из списка свободных буферов выбирается указатель на свободный БфДП, и тот присоединяется к предыдущему.

Задача таймера атомарным образом взаимодействует с задачами (уровнями) подсистемы связи, используя механизм очередей. О применении такого механизма при асинхронных локальных взаимодействиях речь шла ранее. Так как всю подсистему обслуживает единственная задача таймера, эта задача имеет единую входную очередь. Кроме того, как и в случае межуровневых связей, для задачи таймера имеется всего один тип БУС.

Услуги, предоставляемые пользователю задачи таймера, включают в себя запуск и отмену таймера, а также индикацию тайм-аута. Подходящим набором примитивов представляется следующий: ТАЙМЕРстарт (ИДуровня, ИДтаймера, Время), ТАЙМЕРотмена (ИДуровня, ИДтаймера), ТАЙМЕРсрок (ИДтаймера).

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

Для инициирования операций таймера протокольный объект сначала выбирает свободный БУС таймера и вписывает в него в качестве параметров идентификаторы уровня и таймера, а также требуемый интервал времени. Далее он инициирует передачу указателя БУС задаче таймера, выдавая для этого соответствующий межзадачный примитив локальному ядру реального времени. Получив запрос, задача таймера формирует строку таблицы, в которой указывается идентификатор таймера и связанный с этим таймером интервал времени (переменная-счетчик).

Задача таймера управляется прерываниями, поступающими от сигнальных часов. Через определенный период она сначала проверяет наличие в ее входной очереди каких-нибудь БУС, ожидающих обработки. Если таковые имеются, то они подвергаются обработке. Далее, временные интервалы, связанные со всеми активными таймерами, уменьшаются на единицу. Если после этого оказывается, что временной интервал, связанный с каким-либо таймером, истек, то в свободный БУС записывается примитив ТАЙМЕРсрок с параметром, идентифицирующим этот таймер, и указатель БУС с помощью примитива межзадачной связи помещается во входную очередь (от таймеров) соответствующего уровня. В определенный момент по назначении задачи этого уровня к работе этот элемент входной очереди будет выбран и неделимым образом обработан.

Если после инициирования таймера протокольный объект, исходя из приема соответствующих ответов, принимает решение о выключении этого таймера, то он посылает примитив ТАЙМЕРотмена с надлежащими параметрами. используя БУС и примитив межпроцессорной связи, обеспечиваемый ядром реального времени. Когда задача таймера будет в следующий раз назначена к работе, она удалит соответствующий таймер из таблицы таймеров.

Вопросы, связанные с программной реализацией собственно прикладных процессов (ПП) пользователей, выходят далеко за рамки обсуждаемой тематики ВОС. Тем не менее, перед изучением функционирования различных СЭПС, по крайней мере, полезно хотя бы коротко рассмотреть организацию взаимодействия между средами ВОС (СВОС) и реальных систем (СРС).

К настоящему времени на разработку программного обеспечения и взаимосвязанных с ним операционных систем, общение с которыми не подчиняется правилам ВОС, затрачены исключительно большие средства. Очевидна поэтому целесообразность такого подхода, который позволил бы за счет введения и использования относительно малых дополнительных средств осуществить эволюцию таких закрытых систем к системам открытым. Подход, принятый в МОС для достижения этой цели, опирается в основном на отделение СВОС от СРС.

Сначала для определенного приложения описывается виртуальная система и задается набор примитивов службы пользователя, который будет пользоваться этой системой. Все запросы и ответа пользователя на интерфейсе со СВОС относятся к этой виртуальной системе.

Далее между СВОС и ПП, т.е. СРС, создается дополнительное программное обеспечение (ЭП), которое выполняет преобразования в обе стороны между наборами примитивов служб, относящихся к виртуальной системе и к тем, с которыми работает пользователь в СРС, если такие преобразования необходимы. На практике ЭП является набором библиотечных процедур, подключаемых к ПП пользователя.

Ясно, что существует (и будет разрабатываться и далее) большое разнообразие наборов примитивов пользователя, что обусловлено как различиями в типах СЭПС, так и особенностями реализаций приложений. Обычно, однако, можно, во-первых. разделить ПП пользователей на ПП-инициаторы и ПП-респоденты (запрашивающая и отвечающая стороны) и, во-вторых, провести типизацию примитивов, которыми пользуются те и другие.

Примитивы на запрашивающей стороне можно отнести к одному из следующих трех типов: Посылка Сообщения (ПсС), Посылка сообщения с Извещением (ПсСИ), Посылка сообщения с Ответом (ПсСО). Параметры этих примитивов позволяют подключенному ЭП формировать соответствующие примитивы СЭПС. Кроме того, с каждым примитивом связывается параметр состояния, что позволяет ЭП информировать ПП об успешности или безуспешности запроса, и если запрос оказался безуспешным, то и о причине этого.

После передачи примитива ЭП операционная система главной системы приостанавливает ПП пользователя. Трем указанным типам примитива соответствует различная предыстория возобновления этого ПП.

Для примитива типа Посылка Сообщения ПП активизируется сразу после того, как подсистема связи возвращает параметр состояния, связанный с этим примитивом, который указывает либо на успешность посылки (отсюда, из локальной системы), либо на ее недвусмысленность, сообщая о причине неудачи, рис.3.1.4, а). Для примитива ПсС не поступает никаких сведений о том, получил ли предполагаемый корреспондирующий пользователь переданное сообщение. Поэтому обычно этот тип используется в различных связанных с СЭПС службах без подтверждения, выполняемых по установленной ранее ассоциации.

Для примитивов типа ПсСИ ПП пользователя активизируется только после того, как сообщение было доставлено указанному удаленному ПП, и извещение об успешной доставке поступило в систему запрашивающей стороны, рис.3.1.4 б). Поэтому обычно этот тип используется тогда, когда примитивы пользователя относятся непосредственно к службам СЭПС с подтверждением.

Для примитивов типа ПсСО ПП пользователя активизируется только после того, как сообщение было доставлено указанному удаленному ПП и последний прислал ПП запрашивающей стороны ответное сообщение, рис.3.1.4 в). Обычно этот тип используется тогда, когда примитив пользователя охватывает несколько примитивов СЭПС. При этом ПП активизируется только после поступления ответа, связанного с посланным сообщением (запросом). Поскольку параметры, связанные с примитивами этого типа, могут быть использованы для пересылки данных в обоих направлениях, этот тип называют также удаленным вызовом процедур (УВП).

На отвечающей стороне примитивы распадаются на следующие три типа: Получение Сообщения (ПлС), Получение от Любого (ПлЛ), Получение Сообщения с Ответом (ПлСО).

В примитиве типа ПлС ПП отвечающей стороны специфицирует тот (удаленный) ПП, которому он готов отвечать. После выдачи такого примитива ПП либо приостанавливается, пока от указанного ПП не поступит сообщения, либо немедленно активизируется, если уже имеется соответствующее ждущее сообщение. Обычно такой тип примитивов связывают со службами (с подтверждением или без подтверждения) конкретного СЭПС после того, как ассоциация уже установлена.

Примитивы типа ПлЛ подобны примитивам типа ПлС с той лишь разницей, что не осуществляется спецификация ПП, которого отвечающая сторона готова обслужить. Обычно этот тип используется тогда, когда ПП на отвечающей стороне, например, ПП-сервер, готов установить ассоциацию с новым ПП-клиентом. После выдачи примитива ПП либо приостанавливается, пока не поступит новое сообщение, либо немедленно активизируется, если уже имеется ждущее сообщение. Оба типа проиллюстрированы на рис.3.1.4 а) и б).

Примитив типа ПлСО используется совместно с ПсСО для установления двусторонней связи между двумя ПП, т.е. для организации УВП. После получения из входной очереди сообщения (запроса) ПП активизируется и спустя некоторое время вырабатывает ответ, который вручается подсистеме связи и доставляется удаленному ПП на запрашивающей стороне, рис.3.1.4 в).

Ясно, что между двумя взаимодействующими сторонами (процессами) должна быть реализована какая-то форма буферов для хранения сообщений. В этих целях может быть использована память с произвольной выборкой, применение которой для БУС и БфДП описано выше. Эта память входит в состав подсистемы связи и непосредственно адресуется как процессором связи, так и главным процессором.

 

Управление ВОС.

 

В рамках управления ВОС выделены следующие дисциплины: управление при отказах (УО), управление учетом (УУ), управление конфигурацией и именами (УКИ), управление эффективностью функционирования (УЭФ), управление безопасностью (УБ). В этих рамках услуги по обмену информацией предоставляют информационные службы управления (ИСУ), которые являются службами прикладного уровня.

К ресурсам ВОС относятся средства, необходимые для функционирования протоколов ВОС, и данные управления, обеспечивающие информацию о состоянии функционального окружения ВОС.

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

Ресурсами ВОС, имеющими отношение к отчетам о сбоях, являются N-объекты и N-соединения. Тип сбоя определяется независимо от типа ресурса. Имеется четыре класса сбоев, различаемых по степени воздействия сбоя на ресурс: невосстанавливаемый, функциональный, временный и исправимый сбой.

УУ - совокупность средств, обеспечивающих определение стоимости ресурсов и оплаты за их использование. УУ предоставляет средства для оповещения пользователя об оплате или объеме потребления ресурсов, установки учетных лимитов на использование ресурсов, определения стоимости использования совокупности ресурсов. Служба УУ работает с двумя уровнями, на которых доступна информация учета: с сетевым уровнем, учитывающим использование среды связи, и с прикладным уровнем, учитывающим оплату за использование среды связи и ресурсов оконечных систем.

УКИ - совокупность средств управления, идентификации, сбора и предоставления данных, обеспечивающих непрерывное функционирование служб взаимосвязи. Включает средства установки параметров открытых систем, инициализации и закрытия ресурсов ВОС, сбора данных о состоянии открытых систем, обеспечения конкретными данными по запросу.

УЭФ - совокупность средств, необходимых для оценки поведения ресурсов ВОС и эффективности деятельности по взаимосвязи. Сюда относится сбор статистических данных, необходимых для обслуживания и анализа файлов регистрации состояний систем.

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

Реализованные в открытых системах функции управления системами, которые используют ИСУ, обобщенно называются прикладными процессами управления системами (ППУС, SMAP). Часть таких процессов, относящаяся к передаче данных в рамках ВОС, определяется как прикладной объект управления системами (ПОУС).

Элементы ИСУ являются примером специальных элементов прикладной службы (СЭПС), определенных в ЭМВОС.

ПОУС может быть представлен несколькими элементами разных типов: ОЭПС, СЭПС, другими элементами прикладной службы. Взаимодействие двух ПОУС разных открытых систем предполагает наличие между ними ассоциации, устанавливаемой с помощью ЭСУА. Обмен информацией управления по своей природе является в основном двусторонним, где каждая сторона при взаимодействии в рамках одного элементарного обмена выполняет роль инициатора или ответчика.

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

В зависимости от поддерживаемого в каждой открытой системе подмножества функций управления взаимоотношения между ППУС могут изменяться от полностью симметричных до асимметричных. Взаимодействующие при выполнении некоторой задачи управления ППУС могут предварительно осуществлять процедуру согласования своих возможностей по управлению во время фазы установления прикладной ассоциации.

Управление ассоциацией прикладных объектов управления системами (ПОУС) обеспечивается услугами У-ИНИЦИАЛИЗАЦИЯ, У-ЗАВЕРШЕНИЕ, У-РАЗРЫВ, чье использование предполагает применение услуг ЭСУА Пк-АССОЦИИРОВАНИЕ, Пк-ОСВОБОЖДЕНИЕ, Пк-РАЗРЫВ и Пк-Пс-РАЗРЫВ. Помимо этих трех услуг управления ассоциацией, обмен управляющей информацией обеспечивают еще несколько услуг СЭПС ИСУ, чье применение также опирается на использование услуг ОЭПС, конкретнее, на услуги элемента службы удаленных операций (ЭСУО).

Для передачи запроса на пересылку информации (обычно - статистической) от одного ПОУС к другому используется подтверждаемая услуга У-ПОЛУЧЕНИЕ.

Подтверждаемая услуга У-УСТАНОВКА обеспечивает возможность передачи требования другому ПОУС на установку значений атрибутов открытой системы. Установка является основным механизмом управляющих воздействий на ресурсы.

Подтверждаемая услуга У-ДЕЙСТВИЕ обеспечивает возможность передачи требований ПОУС другой открытой системы на выполнение операций. Эта услуга должна использоваться в тех случаях, когда на выполнение операций нельзя воздействовать с помощью установки значений атрибутов.

Индицируемая (неподтверждаемая) услуга У-СОБЫТИЕ обеспечивает уведомление о событии. Используется ПОУС для передачи асинхронных сообщений о ресурсах другому ПОУС. Подтверждаемый вариант этой услуги используется ПОУС для передачи другому ПОУС таких асинхронных сообщений о ресурсах, на которые необходим ответ.

Подтверждаемая услуга У-СРАВНЕНИЕ обеспечивает возможность передачи требования ПОУС другой открытой системы на сравнение значений атрибутов этой открытой системы с заданными значениями и возвращения результатов сравнения.

В число параметров примитивов описанных услуг входят идентификаторы устанавливаемых параметров систем, идентификаторы действий, идентификаторы уровней, идентификаторы событий; величины соответствующих параметров и характеристики действий.

Применяемые услуги ЭСУО - это услуги УО-ВЫЗОВ, УО-РЕЗУЛЬТАТ и УО-ОШИБКА. Услуги ЭСУО предполагают, естественно, использование услуг уровня представлений.

Обычно в каждой подсети имеется система, решающая задачу управления этой подсетью, в то время как остальные ее системы имеют лишь минимальный необходимый набор функций управления. Менеджер (оператор) всей сети управляет подсетью с помощью этой системы, опираясь на централизованный для подсети ППУС - прикладной процесс менеджера сети (ППМС). В его состав входя функциональные компоненты, отвечающие дисциплинам управления: УО, УУ, УКИ, УЭФ и УБ. Соответствующий СЭПС - это элемент менеджера управления системой (ЭМУС), СЭПС в остальных системах подсети - элементы агентов управления системой (ЭАУС), рис.3.2.1. Специфика этих элементов, как видим, состоит в том, что они имеют интерфейс не только с ОЭПС (такой интерфейс имеет всякий СЭПС, и его назначение понятно), но и интерфейс с каждым уровнем. Через этот последний интерфейс осуществляется взаимодействие с функциями управления уровнем, упоминавшимися при рассмотрении каждого из них.

 

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

- число полученных отрицательных Пк-АССОЦИИРОВАНИЕответ, число полученных и посланных ЭСУА-БДП “прекращение” - для ЭСУА (ОЭПС);

- число посланных и полученных ПдСДНотв(-) (ответов “отвергнуто” на запрос на соединение уровня представлений) и Пд-БДП, содержащих код причины: число полученных непонятных Пд-БДП - для уровня представления;

- число полученных и посланных Сн-БДП “отказано”, число полученных и посланных Сн-БДП “прекращение” - для сеансового уровня;

- число имевших место ошибок протокола; число случаев тайм-аута, связанных с переданными Т-БДП, число Ст-БДП, аннулированных в силу неизвестной Ст-ТДС - для сетевого уровня;

- число столкновений и попыток повторных передач (МДКП/ОК, CSMA/CD); число безуспешных передач маркера (шина, управляемая маркером) - для уровня логического звена (подуровня управления логическим каналом) - в рамках ЭМВОС соответствует подуровню канального уровня.

ЭАУС должен обеспечивать средства доступа к таким специальным функциональным параметрам уровня, как, например,

- предел окна - транспортный уровень;

- временные интервалы таймеров - все уровни;

- содержимое таблиц маршрутизации - сетевой уровень;

- допустимый максимум повторных передач (МКДП/ОК);

- желательное время обращения маркера (шина, управляемая маркером).

С дисциплинами управления связана совокупность действий (директив), с помощью которых ППМС выполняет операции с отдельными переменными уровней, относящимися к состоянию и статистики системы. Так, на уровне всей системы ППМС может запросить ЭАУС вернуть в исходное состояние объекты уровней в связи с реконфигурацией. В рамках одного уровня ППМС может запросить у ЭАУС конкретную статистику, и т.д.

Ясно, что все передачи, связанные с выполнением таких действий, инициируются ППМС. Возможны также ситуации, при возникновении которых ЭАУС должны немедленно информировать ППМС о наступлении в присоединенной системе некоторых событий. Например, о достижении в некотором уровне определенными статистическими параметрами заранее установленных пороговых значений.

О сути протокола взаимосвязи менеджера и агента с опорой на услуги компонентов ОЭПС - ЭСУА и ЭСУО - уже шла речь ранее.

 

Служба справочника.

 

Справочная служба (служба справочника) ВОС играет значительную роль во взаимодействии открытых систем. Справочник обеспечивает получение справочной информации, необходимой прикладным процессам ВОС, процессам управления ВОС, другим уровневым объектам и телекоммуникационным средствам. К обеспечиваемым службой справочника возможностям относятся, например, использование ориентированных на пользователя имен для обращения к объектам, поддержание соответствия между именем и адресом.

Одна из причин использования имени - стремление освободить пользователя от необходимость знать конфигурацию используемой сети, ее изменений в ходе подключений/отключений подсетей, например, ЛС, и их компонентов, перемещений прикладных процессов из одного пункта сети в другой. Имена объектов, очевидно, должны быть уникальными, так что в больших межнациональных сетях “имя” может состоять из нескольких компонентов (атрибутов), образующих формат “Страна.Подсеть.Система.Имя”. В итоге, если Имя уникально в системе, то “имя” с гарантией будет уникальным и для всей СВОС.

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

База справочной информации (БСИ) состоит из “входов справочника”, каждый из которых содержит информацию об одном объекте. Имеется два вида входов: объектные и альтернативные. Для каждого конкретного объекта существует только один объектный вход, содержащий первичную информацию об этом объекте. Дополнительно для данного объекта могут присутствовать несколько альтернативных входов.

Входы справочника организованы в дерево, называемое информационным деревом справочника (ИДС). Вершины ИДС, кроме корня, являются входами. Альтернативные входы всегда являются листьями ИДС. Дуги определяют взаимоотношения между вершинами. Дуга от вершины А к вершине В означает, что вход в вершине А является “непосредственно старшим” для входа в вершине В и, наоборот, вход в вершине В является “непосредственно подчиненным” для входа в вершине А.

Каждый вход состоит из множества атрибутов, имеющих заданный тип и одно или более значений. Атрибуты представляют собой отдельные элементы информации, каждый из которых описывает конкретную характеристику объекта. Тип атрибута идентифицирует класс представляемой данным атрибутом информации, например, телефонный номер. В каждом входе имеется не более одного атрибута конкретного класса; при этом один атрибут может иметь несколько значений.

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

Примерами обязательных для каждого входа атрибутов является информация именования, такая как персональное имя, и адресная информация, такая как номер телефона.

Каждый вход имеет атрибут “относительное различаемое имя” (ОРИ), значение которого выбирается так, чтобы относительные различаемые имена всех входов с некоторым одним старшим входом были различными. ОРИ выбирается при создании входа и может быть при необходимости модифицировано.

“Различаемое имя” данного объекта определяется как последовательност