Фрагменты реализации протокола транспортного уровня на лабораторном комплексе
Транспортный уровень.
Общие сведения.
В соответствии с ЭМВОС транспортный уровень выполняет все необходимые процедуры для обеспечения надежной и эффективной прозрачной передачи данных из конца в конец от одного пользователя (сеансового объекта) до другого. Таким образом все протоколы, определенные на транспортном уровне, функционируют в среде ВОС только между оконечными открытыми системами. Транспортный уровень скрывает от пользователей особенности сетевого сервиса.
В фазе установления соединения могут выполняться следующие функции: выбор сетевого соединения, наиболее полно удовлетворяющего требованиям сеансового объекта с учетом стоимости и качества обслуживания; решение о целесообразности мультиплексирования или расщепления транспортного соединения с целью оптимизации использования сетевых соединений; выбор оптимального размера транспортного БДП; выбор функций, которые будут задействованы в фазе передачи данных; отображение транспортных адресов в сетевые; обеспечение идентификации различных транспортных соединений между одной и той же парой транспортных ТДС; передача данных.
В фазе передачи данных осуществляется доведение транспортных БДС до сеансовых объектов-получателей по транспортному соединению передачей транспортных БДП. При этом могут быть задействованы следующие функции, использование каждой из которых согласуется в фазе установления соединения: упорядочение; сегментирование, блокирование и сцепление; мультиплексирование или расщепление; управление потоком; обнаружение ошибок; исправление ошибок; передача срочных данных; разграничение транспортных БДС; идентификация транспортных соединений.
В фазе разъединения соединения могут выполняться функции оповещения о причине разъединения, идентификации разъединяемого транспортного соединения, передачи данных.
При установлении транспортного соединения используются следующие примитивы:
T-CONNECT-request; T-CONNECT-indication; T-CONNECT-response; T-CONNECT-confirmation.
Для разъединения уже установленного соединения, а также при отказе установить соединение используются пара примитивов T-DISCONNECT-request и T-DISCONNECT-indication с соответствующими параметрами. Такая же пара (T-DATA-) с единственным типом параметра - “данные пользователя” - используется при передаче данных по соединению. Длина Т-БДС не ограничена, т.к. на транспортном уровне есть функция разбиения Т-БДС на последовательность Т-БДП.
Для иллюстрации использования в целях описания соотношений примитивов на одном конце соединения диаграмм состояний-переходов приведен рисунок 8.1. для рассматриваемого транспортного сервиса.
Связь параметров качества сервиса транспортного и сетевого уровней иллюстрирована на рисунке 8.2.
Далее воспользуемся конечными автоматами для иллюстрации протокольной спецификации фрагмента фазы установления транспортного соединения. На рисунке 8.3. приведены части списков имен элементов множеств входных и выходных событий, состояний автомата, разрешающих условий (предикатов).
Предикату соответствует булевская переменная, зависящая от комбинации значений параметров, связанных с входным событием, и текущего состояния одной или нескольких автоматных переменных. Если предикатное условие не выполнено, а альтернатива не определена, то говорят, что имела место ошибка протокола. В этом случае выдается заранее определенное выходное событие, и автомат переходит в соответствующее состояние.
На рисунке 8.4. дан фрагмент соответствующей таблицы состояний-переходов автомата. Здесь он выписан в виде таблицы ссылок на список комбинаций состояний-событий. Некоторые из этих комбинаций обусловлены предикатами. В имеющемся фрагменте ни в одной из ситуаций никаких специальных действий, например, запуска или остановки таймера, не производится, так что ссылочный список таких действий здесь пуст.
Фрагменты реализации протокола транспортного уровня на лабораторном комплексе.
Простейший протокол транспортного уровня, фактически является заглушкой и не выполняет основной задачи транспортного уровня - исправление и снижение количества ошибок.
Событие T_CONNECT.REQ:
down N_CONNECT.REQ address $address
Событие N_CONNECT.IND:
up T_CONNECT.IND
Событие T_CONNECT.RESP:
down N_CONNECT.RESP address $address
Событие N_CONNECT.CONF:
up T_CONNECT.CONF
Событие T_DATA.REQ:
down N_DATA.REQ userdata $userdata address $address
Событие N_DATA.IND:
up T_DATA.IND userdata $userdata
Событие T_DISCONNECT.REQ:
down N_DISCONNECT.REQ address $address
Событие N_DISCONNECT.IND:
up T_DISCONNECT.IND
В рамках лабораторного практикума основная задача транспортного уровня - снижение количества ошибок при установлении соединения и передачи данных при сохранении приемлемой скорости работы системы. Основным методом борьбы с ошибками при установлении соединения является повторная попытка установлении соединения, а при передаче данных - повторная пересылка данных. Кроме того, при передаче данных необходимо вести контроль за искажением и появлением дубликатов БДП (блок данных протокола). Это делается с помощью подсчета контрольной суммы и нумерации БДП соответственно.
Простой метод борьбы с ошибками при установлении соединения (Соединяется Система A c Системой B):
Система A:
Событие T_CONNECT.REQ:
set addrB $address
down N_CONNECT.REQ address $addrB
; послать запрос на соединение
set connect_try 5
; поставить пять попыток соединения
timer con_try CONNECT_TRY 200
; запустить таймер на проверку установления соединения
Событие N_CONNECT.CONF:
untimer $con_try
; соединение установлено - выключить таймер
up T_CONNECT.CONF
; послать подтверждение установления соединения
Событие CONNECT_TRY:
set connect_try $connect_try-1
; уменьшить количество попыток соединения
if $connect_try == 0 terminate
; попытки соединения кончились?
down N_CONNECT.REQ address $addrB
; послать запрос на соединение
timer con_try CONNECT_TRY 200
; запустить таймер на проверку установления соединения
goto exit
terminate:
down N_DISCONNECT.REQ address $addrB
; попытки соединения кончились - разрыв соединения
up T_DISCONNECT.IND
; послать индикацию разрыва соединения
exit:
Система B:
Событие N_CONNECT.IND:
up T_CONNECT.IND
Событие T_CONNECT.RESP:
set addrA $address
down N_CONNECT.RESP address $addrA
В этом примере разбирается простейший случай, исправляется только потеря запроса на соединение путем повторных попыток установления соединения при возникновении ошибки. Всего система пытается соединится пять раз. Обратите внимание на то, что после каждой неудачной попытки соединения система посылает запрос на разрыв сетевого соединения, и только после этого производит следующую попытку. Это необходимо, т.к. потеря запроса могла произойти во время ответа Системы В Системе А, после чего Система В будет находится в состоянии “соединено” и игнорировать все попытки соединения.
На рисунке 8.2.1 представлена диаграмма состояний конечного автомата соответствующего примеру, в таблице 8.2.1 соответствующая им таблица состояний-переходов, а в таблицах 8.2.2, 8.2.3 и 8.2.4 списки входных, выходных событий и состояний автомата соответственно.
Рис. 8.2.1. Диаграмма состояний конечного автомата фазы установления транспортного соединения.
Таблица 8.2.1. Таблица состояний-переходов.
| Состояние | Входное событие | |||
| T_CON.REQ | N_CON.CONF | CON_TRY | * | |
| 2,- | -,- | -,- | -,- | |
| -,- | -,- | -,- | 3,N_CON.REQ | |
| -,- | 4,T_CON.CONF | 5,N_CON.REQ | -,- | |
| -,- | -,- | -,- | -,- | |
| -,- | 4,T_CON.CONF | 6,N_CON.REQ | -,- | |
| -,- | 4,T_CON.CONF | 7,N_CON.REQ | -,- | |
| -,- | 4,T_CON.CONF | 8,N_CON.REQ | -,- | |
| -,- | 4,T_CON.CONF | 9,N_CON.REQ | -,- | |
| -,- | -,- | -,- | -,- |
Таблица 8.2.2. Список входных событий.
| Входное событие | Смысл / значение |
| T_CON.REQ | Получен Т_СОЕДИНЕНИЕзапрос |
| N_CON.CONF | Получен Ст_СОЕДИНЕНИЕподтверждение |
| CON_TRY | Получено сообщение от таймера |
| * | Пустой входной сигнал |
Таблица 8.2.3. Cписок выходных событий.
| Выходное событие | Смысл / значение |
| N_CON.REQ | Послан Ст_СОЕДИНЕНИЕзапрос |
| T_CON.CONF | Послан Т_СОЕДИНЕНИЕподтверждение |
| T_DISCON.REQ | Послан Т_РАЗЪЕДИНЕНИЕзапрос |
| N_DISCON.REQ | Послан Ст_РАЗЪЕДИНЕНИЕзапрос |
Таблица 8.2.3. Cписок состояний автомата.
| Состояние | Смысл / значение |
| Начальное состояние | |
| Пришел запрос на установление транспортного соединения | |
| Послан первый запрос на установление сетевого соединения | |
| Пришло подтверждение установления сетевого соединения, транспортное соединение установлено | |
| Подтверждение установления сетевого соединения не пришло, послан второй запрос на установление сетевого соединения | |
| Подтверждение установления сетевого соединения не пришло, послан третий запрос на установление сетевого соединения | |
| Подтверждение установления сетевого соединения не пришло, послан четвертый запрос на установление сетевого соединения | |
| Подтверждение установления сетевого соединения не пришло, послан пятый запрос на установление сетевого соединения | |
| Подтверждение установления сетевого соединения не пришло, попытка установления транспортного соединения не успешна |
При передаче данных потеря БДП обнаруживается и исправляется аналогичным механизмом подтверждения и передачи данных при их потере. Кроме того, для обнаружения искажения БДП необходимо вводить контрольную сумму, и при обнаружении несоответствия БДП контрольной сумме сбрасывать БДП. В случае правильно организованного механизма обнаружения потери БДП это приведет к повторной передаче БДП. Для обнаружения дубликатов БДП необходимо ввести нумерацию БДП и сбрасывать все просроченные БДП.
Формирование и распаковка БДП:
Допустим нужен БДП: [номер БДП][данные]
Формирование:
{num_pac - переменная с номером БДП; data - буфер с данными; buf - искомый БДП }
buffer buf sizeof(data)+4 $num_pac 4 $data sizeof(data)
Это просто. Распаковка (в другой системе и событии):
{ num_pac - переменная в которой будет номер принятого БДП; data - буфер в который распакуют данные; buf - БДП, который распаковывают}
set num_pac 0
buffer 20 data 0 4
unbuffer buf num_pac 4 data sizeof(buf)-4
Тоже самое, но с проверкой на искажение БДП:
БДП: [crc(4байта)][номер БДП (4байта)][данные]
Формирование:
{num_pac - переменная с номером БДП; data - буфер с данными; buf - искомый БДП; buf1- промежуточный буфер; crc - контрольная сумма}
buffer buf1 sizeof(data)+4 $num_pac 4 $data sizeof(data)
crc crc $buf1
buffer buf sizeof(data)+8 $crc 4 $buf1 sizeof(data)+4
Это просто. Распаковка (в другой системе и событии):
{num_pac - переменная в которой будет номер принятого БДП; data - буфер в который распакуют данные; buf - БДП, который распаковывают; crc - контрольная сумма в БДП; crc1 - контрольная сумма заново подсчитанная ; buf1- промежуточный буфер}
set num_pac 0
; инициализация номера БДП
set crc1 0
; инициализация контрольной суммы
buffer 20 data 0 4
; инициализация буфера
buffer 20 buf1 0 4
; инициализация буфера
unbuffer buf crc 4 buf1 sizeof(buf)-4
; распаковка БДП в промежуточный буфер
crc crc $buf1
; подсчет контрольной суммы
if $crc != $crc1 corrupted
; проверка на искажение
;пакет не искажен
unbuffer buf1 num_pac 4 data sizeof(data)-8
; распаковка БДП
...
goto exit
:corrupted
; БДП искажен
...
goto exit
...
:exit
Все вышесказанное относится к случаю, когда используются сетевые службы с установлением соединения. При использовании сетевой службы без установления соединения отличия сводятся к следующему:
нет необходимости устанавливать и разрывать сетевое соединение;
в БДП транспортного уровня вводится поле их назначения (данные пользователя, системная информация), т. е. формат БДП будет следующий:
| контрольная сумма | номер БДП | Назначение | Данные |
Методы исправления ошибок передачи данных остаются теми же, что и в случае использования сетевой службы с установлением соединения (нумерация и подсчет контрольной суммы БДП). Кроме того, необходимо ввести подтверждение приема БДП в целях обнаружения потери БДП. Такое подтверждение необходимо и для случая при использовании сетевой службы с установлением соединения.
Сеансовый уровень.
1.1 Общие положения.
Сеансовый уровень с установлением соединения обеспечивает средства организации и синхронизации обмена данными между пользователями. Функции сеансового уровня сильно связаны с его сервисом, т.к. собственные, т.е. не инициированные с верхнего уровня, действия на сеансовом уровне практически отсутствуют. В целом, сеансовый уровень (с помощью служб, обеспечиваемых уровнем представления) предоставляет прикладным объектам следующие средства равноправного, синхронизированного, структурированного взаимодействия:
- установления сеансового соединения, синхронизированного обмена данными, упорядоченного и безусловного завершения сеансового соединения;
- согласование использования маркеров обмена данными, синхронизации и завершения взаимодействия, а также фиксации маркеров на одной из взаимодействующих сторон;
- установления точек синхронизации внутри диалога;
- выполнения ресинхронизации сеансового соединения, т.е. возврата к согласованной прикладными объектами точке синхронизации;
- прерывания диалога и его возобновления с заранее организованной точки синхронизации.
Сеансовая служба содержит три фазы: установления сеансового соединения, передачи данных, освобождения сеансового соединения.
В фазе установления соединения предусмотрена одна услуга, S-CONNECT которая позволяет согласовать его параметры, распределить маркеры, выбрать начальный номер точки синхронизации.
В фазе передачи данных осуществляется синхронизированный обмен данными между двумя пользователями сеансовой службы. Для передачи данных используется услуга
S-DATA, для управления расположением маркеров услуги S-GIVE-TOKENS, S-PLEASE-TOKENS, S-GIVE-CONTROL и для фиксации точек синхронизации и ресинхронизации услуги S-SYNC-MINOR, S-SYNC-MAJOR, S-RESYNCHRONIZE.
Фаза завершения сеансового соединения характеризуется тремя другими услугами: S-RELEASE - упорядоченное завершение (может быть использован маркер завершения TR), S-P-ABORT и S-U-ABORT - безусловное завершение.
Некоторые услуги могут инициироваться и поставщиком (Пс, provider, P), и пользователем (Пл, user, U), например, услуги безусловного завершения сеансового соединения - соответственно S-P-ABORT и S-U-ABORT.
Качество сеансового сервиса. Определяет параметры сеансового соединения, которые касаются исключительно поставщика сеансовой службы. Параметры делятся на два типа. Параметры первого типа согласуются в ходе установления сеансового соединения. К ним относятся: защита сеансового соединения. Параметры второго типа не согласуются в фазе установления сеансового соединения, но их значение известно либо изначально, либо в результате проведения предварительных измерений. К ним относятся: задержка установления сеансового соединения, вероятность отказа в установлении сеансового соединения, вероятность ошибки передачи, задержка завершения сеансового соединения, вероятность ошибки завершения сеансового соединения.
После установления соединения СнСл-пользователи не могут модифицировать выбранные параметры качества сеансового сервиса в период существования этого соединения. Поставщик сеансовой службы не информирует СнСл-пользователей о каких-либо изменениях параметров качества сеансового уровня.
Надо заметить, что формат БДП меняется в зависимости от параметров согласуемых в ходе установления сеансового соединения. Так при отключении защиты исчезает поле ответственное за защиту.
Поставщик сеансовой службы для обеспечения сеансового соединения использует транспортное соединение. В каждый момент времени существует однозначное соответствие между сеансовым и транспортным соединениями, каждому сеансовому соединению соответствует единственное транспортное соединение. Однако время их жизни может отличаться: одно транспортное соединение может поддерживать несколько последовательных сеансовых соединений, несколько последовательных транспортных соединений могут поддерживать одно сеансовое.
Транспортное соединение, об использовании которого шла речь, либо должно быть установлено путем инициации поставщиком сеансовой службы услуги T-CONNECT, либо захвачено им же - в случае, если среди зарезервированных сеансовым объектом впрок имеется подходящее. При благополучном развитии ситуации после этого корреспондирующие сеансовые объекты обмениваются по этому транспортному соединению, пользуясь услугами T-DATA, данными, которые необходимы для установления сеансового соединения.
Воспользуемся здесь формализмом конечных автоматов для протокольной спецификации, как и в случае транспортного уровня, фрагмента фазы установления сеансового соединения. В иллюстративных целях была избрана фаза установления соединения для основного комбинированного подмножества. Ему соответствует набор из 11 типов Сн-БДП, формируемых Сн-объектом.
На рисунке 1.1.1 приведены части списков имен элементов множеств входных и выходных событий, состояний автомата, предикатов и специальных действий.
На рисунке 1.1.2 приводится фрагмент соответствующей таблицы состояний-переходов автомата.
1.2 Службы сеансового уровня.
На рисунке 1.2.1 (б) приведена диаграмма временной последовательности взаимодействия основных служб обеспечиваемых сеансовым уровнем. Как можно увидеть, с каждым примитивом связаны некоторые параметры. Так как транспортный и сеансовый уровни совместно образуют функцию, осуществляемую в интересах уровня представления, то результатом действия большинства из изображенных примитивов служб сеансового уровня оказываются соответствующие блоки данных сеансового протокола (СнБДП), формируемых на основании параметров, связанных с примитивами (рисунок 1.2.1(а)).
а)
б)
Рис. 1.2.1. Основные службы сеансового уровня (б) и связанные с ним транспортные службы (а).
Таким образом
| СнБДП | Посланы в ответ на: |
| СОЕДИНЕНИЕ, СД | Сн.СОЕДИНЕНИЕ.запрос |
| ПРИНЯТО, ПН | Сн.СОЕДИНЕНИЕ.ответ(успешный) |
| ОТКАЗАНО, ОТ | Сн.СОЕДИНЕНИЕ.ответ(безуспешный) |
| ДАННЫЕ, ДН | Сн.ДАННЫЕ.запрос |
| ЗАПРОС МАРКЕРА, ЗМ | Сн.ЗАПРОС_МАРКЕРА. запрос |
| ПЕРЕДАЧА МАРКЕРАБ, ПМ | Сн.ПЕРЕДАЧА_МАРКЕРА. запрос |
| КОНЕЦ, КН | Сн.ОСВОБОЖДЕНИЕ.запрос |
| РАЗЪЕДИНЕНИЕ, РЗ | Сн.ОСВОБОЖДЕНИЕ.ответ |
| ПРЕКРАЩЕНИЕ, ПКР | Сн.Пл_ПРЕКРАЩЕНИЕ.запрос |
| ПРЕКРАЩЕНИЕ ПРИНЯТО, ППН | Получение ПКР |
2. Фрагменты реализации протокола сеансового уровня на лабораторном комплексе.
Основной задачей сеансового уровня (в контексте данной части ДЗ) является предоставление прикладным объектам (с помощью служб, обеспечиваемых уровнем представления) следующих средств взаимодействия:
- установления сеансового соединения, синхронизированного обмена данными, упорядоченного и безусловного завершения сеансового соединения;
- согласование использования маркеров обмена данными, синхронизации и завершения взаимодействия, а также фиксации маркеров на одной из взаимодействующих сторон;
- установления точек синхронизации внутри диалога;
- выполнения ресинхронизации сеансового соединения, т.е. возврата к согласованной прикладными объектами точке синхронизации.
Синхронизация необходима для проверки правильности передачи данных: передачу в нужном порядке, без потери и дубляжа БДП. Услуга ресинхронизации вызывается в случае нарушения синхронизации или проблем с маркерами (потерей или дубляжом). В случае отсутствия услуги ресинхронизации сеансовый протокол фактически может работать до первой ошибки. Так при потере маркера протокол фактически зависнет, при дубляже маркеров произойдет потеря синхронизации.
Сеансовая служба содержит три фазы: установления сеансового соединения, передачи данных, освобождения сеансового соединения.
В фазе установления соединения предусмотрена одна услуга, S-CONNECT.
Пример простейшей организации услуги S-CONNECT без каких-либо параметров:
событие S_CONNECT.REQ:
down T_CONNECT.REQ address $sysB
событие T_CONNECT.IND:
up S_CONNECT.IND
событие S_CONNECT.RESP:
down T_CONNECT.RESP address $sysA
событие T_CONNECT.CONF:
up S_CONNECT.CONF
где sysB - адрес вызываемой системы, а sysA - адрес вызывающей системы.
При установлении соединения с некоторыми параметрами (например, использование защиты от ошибок или начальная расстановка маркеров) после установления транспортного соединения необходимо согласовать (передать) эти параметры, используя примитивы передачи данных и только после этого индицировать установление соединения на вышележащий уровень. Диаграмма состояний соответствующего конечного автомата представлена на рисунке 2.1, а в таблицах 2.1, 2.2 и 2.3 списки входных, выходных событий и состояний автомата соответственно. В целях увеличения надежности работы протоколов рекомендуется дополнить данную схему средствами исправления ошибок (при установлении соединения), аналогичными средствам транспортного уровня. В данном примере система А является инициирующей соединение, система В отвечает.
Таблица 2.1. Список входных событий.
| Входное событие | Смысл / значение |
| S_CON.REQ | Получен С_СОЕДИНЕНИЕзапрос |
| T_CON.CONF | Получен Т_СОЕДИНЕНИЕподтверждение |
| T_DATA.IND2 | Получен Т_ДАННЫЕиндикация - параметры согласованы |
| T_DATA.IND1 | Получен Т_ДАННЫЕиндикация - список параметров |
| T_CON.IND | Получен Т_СОЕДИНЕНИЕиндикация |
Таблица 2.2. Cписок выходных событий.
| Выходное событие | Смысл / значение |
| T_CON.REQ | Послан Т_СОЕДИНЕНИЕзапрос |
| T_DATA.REQ1 | Послан Т_ДАТАзапрос - список параметров |
| S_CON.CONF | Послан С_СОЕДИНЕНИЕподтверждение |
| T_CON.RESP | Послан Т_СОЕДИНЕНИЕответ |
| T_DATA.REQ2 | Послан Т_ДАТАзапрос- параметры согласованы |
| S_CON.IND | Послан С_СОЕДИНЕНИЕиндикация |
Таблица 2.3. Cписок состояний автомата.
| Состояние | Смысл / значение |
| 1А, 1В | Начальное состояние |
| 2А | Пришел запрос на установление сеансового соединения |
| 3А | Послан запрос на установление транспортного соединения |
| 4А | Пришло подтверждение установления транспортного соединения |
| 5А | Послан список параметров |
| 6А | Пришел ответ - параметры согласованны |
| 7А | Сеансовое соединение установлено |
| 2В | Пришла индикация установления сеансового соединения |
| 3В | Послан ответ установления транспортного соединения |
| 4В | Пришел список параметров |
| 5В | Послано - параметры согласованы, Сеансовое соединение установлено |
В фазе передачи данных осуществляется синхронизированный обмен данными между двумя пользователями сеансовой службы. Для передачи данных используется услуга S-DATA, для управления расположением маркеров услуги S-GIVE-TOKENS, S-PLEASE-TOKENS и для фиксации точек синхронизации и ресинхронизации услуги S-SYNC-MINOR, S-SYNC-MAJOR, S-RESYNCHRONIZE.
В простейшем случае во время фазы передачи данных для собственно передачи данных, а также для синхронизации и управления маркерами, достаточно пользоваться БДП следующего типа:
| Идентификатор | данные |
где идентификатор определяет тип БДПа, а данные - соответствующие данные. В этом случае услуга S-DATA выглядит следующим образом:
Обработка события S_DATA.REQ:
if $DK!=1 gettoken если маркера DK нет, то перейти к gettoken
if qcount(outgoingq)==0 send если очередь посылаемых БДП
queue outgoingq $userdata пуста, то послать, иначе поместить в
goto exit очередь
send:
buffer buf1 8 3 4 $userdata 4 составить БДП с идентификатором 3
down T_DATA.REQ userdata $buf1 и послать его
set SP $SP+1 увеличить число прошедших БДП
queue senddata $userdata поместить данные в очередь неподтвержденных данных
goto exit
gettoken:
timer timer45 S_RESYNC.REQ 0 token 1 запустить запрос на ресинхронизацию
queue outgoingq $userdata и поместить данные в очередь
goto exit
exit:
На удаленном конце сеансового соединения соответствующее событие (на сеансовом уровне) происходит при получении с транспортного уровня примитива T_DATA.IND. Его обработчик может выглядеть в данном случае так:
Обработка события T_DATA.IND:
set ID 4
buffer data 4 4 4
unbuffer userdata ID 4 data 4 определить тип БДП по идентифи-
if $ID == 1 major_sync_ind катору и перейти к соответствующему
if $ID == 2 minor_sync_ind обработчику
if $ID == 3 data_ind
if $ID == 4 major_sync_conf
if $ID == 5 resync_ind
if $ID == 6 resync_conf
if $ID == 7 give_toc_ind
if $ID == 8 please_toc_ind
if $ID == 9 release_ind
if $ID == 10 u_abort_ind
goto exit
major_sync_ind:
timer t0 S_SYNC_MAJOR.IND 0 syncpoint $data
goto exit
minor_sync_ind:
timer t0 S_SYNC_MINOR.IND 0 syncpoint $data
goto exit
data_ind:
set SP $SP+1 увеличить число прошедших БДП
queue ingoingq $data поместить данные в очередь неподтвержденных данных
if $SP % $SN == 0 major_sync если принято SN БДП послать запрос на основную синхронизацию,
goto exit где SN - количество данных, после которого необходимо проводить синхронизацию
(определяется в ходе установления соединения)
major_sync:
timer t0 S_SYNC_MAJOR.REQ 0
goto exit
major_sync_conf:
timer t0 S_SYNC_MAJOR.CONF 0 syncpoint $data
goto exit
resync_ind:
timer t0 S_RESYNC.IND 0 syncpoint $data
goto exit
resync_conf:
timer t0 S_RESYNC.CONF 0 syncpoint $data
goto exit
give_toc_ind:
timer t0 S_GIVE_TOKEN.IND 0 syncpoint $data
goto exit
please_toc_ind:
timer t0 S_PLEASE_TOKEN.IND 0 syncpoint $data
goto exit
release_ind:
timer t0 S_RELEASE.IND 0 syncpoint $data
goto exit
u_abort_ind:
timer t0 S_U_ABORT.IND 0 syncpoint $data
goto exit
goto exit
exit:
где DK - маркер данных (1-маркер назначен, 0-маркер не назначен); ID - идентификатор БДП (значения идентификатора указаны в таб. 2.4.); data - данные БДП; senddata - очередь с посланными, но не подтвержденными БДП; outgoingq - очередь с посылаемыми БДП; ingoingq - очередь с принятыми, но не подтвержденными БДП.
Таблица 2.4. Значения идентификатора.
| идентификатор | Значение |
| Индикация главной синхронизации | |
| Индикация вспомогательной синхронизации | |
| Индикация передачи данных | |
| Подтверждение главной синхронизации | |
| Индикация ресинхронизации | |
| Подтверждение ресинхронизации | |
| Индикация передачи маркера | |
| Индикация запроса маркера | |
| Индикация упорядоченного завершения | |
| Индикация безусловного завершения пользователя |
В случае введения защиты в условиях лабораторного программного комплекса можно ограничится средствами защиты, аналогичным средствам защиты транспортного уровня. Т.е. необходимо введение дополнительного поля, содержащего контрольную сумму данных, в БДП данных, и его соответствующей обработки. Это поле и его обработка аналогичны средствам защиты транспортного уровня, описанным в материале, посвященном транспортному уровню. При этом стоит заметить, что если протокол поддерживает защиту, но при установлении соединения защита была отключена, то поле защиты исключается и его обработка, разумеется, не производится.
Для управления расположением маркеров достаточно передать соответствующий БДП, как это указано выше, переустановить значения переменных, отвечающих за расположение маркеров, и убедиться, что не произошло потери или дублирования маркера.
Синхронизация необходима для проверки правильности передачи данных: передачу данных в нужном порядке, без потери и дубляжа БДП. Для этого БДП нумеруются, и во время вызова услуг малой и основной синхронизации проверяется правильность передачи.
Услуга ресинхронизации вызывается в случае нарушения синхронизации или проблем с маркерами (потерей или дубляжом). Во время выполнения этой услуги происходит согласование маркеров, а также повторная передача всех данных, не подтвержденных услугой основной синхронизации.
Фаза завершения сеансового соединения характеризуется тремя услугами: S-RELEASE - упорядоченное завершение, S-P-ABORT и S-U-ABORT - безусловное завершение. Основным отличием этих услуг является то, что при упорядоченном завершении не происходит потери данных, а при безусловном эта потеря может произойти. Фактически услуги S-P-ABORT и S-U-ABORT являются аналогом услуги транспортного уровня T_DISCONNECT. Услуга S_RELEASE отличается от них тем, что после прихода ее запроса участники сеансового соединения перед разрывом соединения пытаются переслать все не посланные данные. Пример простейшей организации услуги:
Обработка события S_P_ABORT.REQ:
buffer buf 8 10 4 $SP 4 создать БДП данных
down T_DATA.REQ userdata $buf отослать их другой системе
down T_DISCONNECT.REQ разорвать соединение
Уровень представления.
1.1 Общие положения.
Оконечные системы (абоненты) вычислительных сетей весьма разнообразны и представлены устройствами различных типов - от простых символьно-ориентированных дисплеев до универсальных ЭВМ и систем, ориентированных на базы данных. В разных устройствах используется различное внутренне представление хранимой информации. Для обеспечения их взаимодействия модель ВОС содержит шестой уровень, называемый уровнем представления (представительным уровнем).
В процессе своего функционирования объекты уровня представления используют протокол, который позволяет согласовать различия в синтаксисе данных с помощью преобразования местного представления (локальный синтаксис) в синтаксис передачи. Синтаксис передачи вместе с правилами преобразования составляет образ конкретного соединения уровня представления. Согласования синтаксических различий должно выполняться таким образом, чтобы сохранить семантику передаваемой информации.
Представительный уровень в ходе согласования синтаксических различий имеет дело с двумя аспектами. Первый относится к описанию (заданию) синтаксиса со стороны прикладных объектов, второй - к тому, как описанные заданным синтаксисом данные выражаются в терминах представления их значений в среде ВОС. Первый аспект обозначается термином абстрактный синтаксис, второй - синтаксис передачи.
Конкретная семантика прикладных систем может быть выражена с помощью различных абстрактных синтаксисов АС1, …, АСn - см. рис. 1.1.1, каждый из которых использует одинаковые или различные синтаксисы передачи СП1, …, СПm.
Семантика
АС1 … АСn
СП1 … СПm … СП1 … СПm
Рис. 1.1.1. Связь семантики, абстрактных синтаксисов и синтаксисов передачи.
В общем случае не предполагается однозначного соответствия между конкретными абстрактными синтаксисами и синтаксисами передачи. Сервис представительного уровня позволяет устанавливать такие соотношения динамически. Например, при использовании одного и того же абстрактного синтаксиса передача может происходить с шифрацией или без шифрации, со сжатием или без сжатия передаваемой информации.
Функция согласования синтаксисов передачи поддерживается механизмом переговоров, выполняемым в соответствии с представительным протоколом.
Таким образом, двумя основными функциями уровня представления являются согласование синтаксиса передачи и преобразование (в обе стороны) между абстрактным синтаксисом и синтаксисом передачи. Это преобразование выполняется в рамках представительного объекта невидимым со стороны представительного протокола способом, чем обеспечивается отсутствие влияния таких преобразований на протокол - он имеет дело лишь с использованием системы идентификации синтаксисов передачи.
К другим функциям уровня представления относятся функция запроса на установление и на прекращение сеанса, передачи данных.
При каждом случае передачи без установления соединения уровень представления добавляет к сеансовой службе вызываемые услуги преобразования синтаксиса и выбора синтаксиса. Для их обеспечения уровень представления выполняет функции передачи данных, идентификации синтаксиса и его преобразования.
Возможности, предоставляемые уровнем представления своим пользователям, отнесены к следующим категориям, каждая из которых объединяет ряд функционально схожих услуг:
- установление и завершение соединения,
- управление контекстами,
- передача информации,
- управление диалогом.
Работа с заданным множеством контекстов зависит от выбираемых на этапе установления соединения функциональных групп (блоков) - логических объединений связанных между собой услуг. Такие объединения используются для указания требований пользователя представительной службы во время установления соединения.
Выделяются три функциональные группы: ядра (базовая), управления контекстами, восстановления контекстов.
Функциональная группа ядра доступа всегда, она обеспечивает услуги установления соединения, передачи информации и завершения соединения. Передача информации поддерживается при использовании выбранных сеансовых функциональных групп. Если выбрана только эта группа, то множество заданных на этапе установления представительного соединения контекстов в дальнейшем во время существования этого соединения не может быть изменено. Эта функциональная группа устанавливается по умолчанию.
Функциональная группа управления контекстами должна явно заказываться и согласовываться при установлении представительного соединения. Если она согласована, то множество заданных контекстов может быть изменено во время существования соединения. Услуга, с использованием которой это достигается, может конфликтовать с другими услугами уровня представления, обладающими т.н. разрушающими воздействиями. Такие конфликты могут привести к рассогласованию множества заданных контекстов на разных концах соединения. В этом случае возможно получение данных в контексте, неизвестном представительному объекту, о чем он будет сообщать пользователю: “нечитаемые данные”. В то же время пользователи представительного сервиса могут избежать таких конфликтов корректным использованием маркеров.
Функциональная группа восстановления явно заказывается и согласовывается при установлении представительного соединения, причем в этом случае также должна быть заказана функциональная группа управления контекстами. Выбор функциональной группы восстановления дает возможность запоминать множества заданных контекстов в специфицированных точках во время существования представительного соединения. В дальнейшем пользователь представительного сервиса может затребовать возврат к одной из запомненных точек, а сервис представительного уровня обеспечивает корректное восстановление контекстов, существовавших в этой точке. Точками запоминания могут служить точки главной или вспомогательной синхронизации, прерывания активности, установления соединения.
Ход процессов восстановления и управления контекстами во избежание рассогласования контекстных множеств на концах соединения должен подчиняться ряду правил, опирающихся, в частности, на использование маркеров и номеров точек запоминания.
1.2 Службы уровня представления.
На рисунке 1.2.1 (а) приведена диаграмма временной последовательности взаимодействия основных служб обеспечиваемых уровнем представления. Как можно увидеть, с каждым примитивом связаны некоторые параметры. Так как уровень представления и сеансовый уровень совместно образуют функцию, осуществляемую в интересах прикладного уровня, то результатом действия большинства из изображенных примитивов служб уровня представления оказываются соответствующие блоки данных протокола представления (ПдБДП), формируемых на основании параметров, связанных с примитивами (рисунок 1.2.1(б)).
а)
Рис. 1.2.1. Основные службы уровня представления (а) и связанные с ним сеансовые службы (б).
Таким образом
| Приметив службы | Формирует ПдБДП |
| Пд.СОЕДИНЕНИЕ.запрос | Соединение уровня представления ПдСд |
| Пд.СОЕДИНЕНИЕ.ответ(+) | Соединение уровня представления принято ПдСдПН |
| Пд.СОЕДИНЕНИЕ.ответ(-) | Соединение уровня представления отказано ПдСдОТ |
| Пд.ДАННЫЕ.запрос | Передача данных уровня представления ПдДн |
| Пд.Пл_ПРЕКРАЩЕНИЕ.запрос | Ненормальное освобождение(пользователь) ПлПКР |
| Пд.Пс_ПРЕКРАЩЕНИЕ.индикация | Ненормальное освобождение(поставщик) ПсПКР |
Наконец, имеются несколько примитивов службы представления, которые без какой-либо модификации отображаются на соответствующие примитивы СнСлбез формирования ПдБДП. Обычно параметры, связанные такими примитивами, передаются в поле данных пользователя соответствующего примитива СНСл. В число таких примитивов входят примитивы службы Пд.ОСВОБОЖДЕНИЕ, а также примитивы обеспечивающие функции управления синхронизацией, управления жетонами и др.
1.3 Автоматная модель.
На рисунке 1.3.1 выписаны частичные списки имен элементов множеств входных и выходных событий, состояний автомата, предикатов и специальных действий.
На рисунке 1.3.2 приведена часть соответствующей таблицы состояний-переходов.
2. Абстрактные синтаксисы и синтаксисы передачи.
Нотация абстрактного синтаксиса должна обеспечивать определение сложных типов данных и задание значений этих типов без указания способа представления (в виде последовательности октетов) отдельных экземпляров этих типов во время передачи.
В текущей версии лабораторного комплекса потребности приложений разработчики ограничили стремлением представить взаимосвязь прикладных процессов в виде элементарных взаимодействий простых моделей двух животных. В итоге в настоящее время, помимо таких типов, как число, строка и буфер - они стандартны для встроенного языка комплекса - необходимыми представляются следующие основные типы - звук, движение, цвет, запах и структура.
Из рис. 1.1.1 видно, что возможны различные способу выражения семантики абстрактным синтаксисом и абстрактных синтаксисов синтаксисами передачи. Так, различная семантика может использовать различный - рис. 2.1.а, или одинаковый - рис. 2.1.б - абстрактный синтаксис с одинаковым синтаксисом передачи. Для указания приемлемой комбинации абстрактного синтаксиса и синтаксиса передачи используется термин “контекст представления”.
Семантика 1 Семантика 2 Семантика 1 Семантика 2
АС1 АС2 АС
СП СП
а) б)
Рис. 2.1. Семантика, абстрактные синтаксисы и синтаксис передачи.
Как и ASN. 1, абстрактные синтаксисы лабораторного комплекса - это средства со строгой типизацией, с явным описанием используемых типов. В текущей версии комплекса в целях упрощения во всех версиях применяются структуры фиксированного вида - звук, движение, цвет, запах - различаться будут лишь разделители. Пример такой структуры: {{мяу}{прыгнул}{серый}{}} (в приведенном примере разделитель - это фигурные скобки {}).
Уже шла речь о том, что каждому абстрактному синтаксису может соответствовать множество синтаксисов передачи, см. рис. 1.1.1. Синтаксис передачи задают правила кодирования, определяющие значения потока октетов между объектами уровня представления. В текущей версии комплекса из возможного множества наборов таких правил используется т.н. базовый набор правил кодирования ASN. 1, принятый в настоящее время в качестве стандарта МОС.
Таким образом, в лабораторном практикуме используются два способа указания длины содержимого, которые рекомендованы МОС. Это кодирование с явным указанием длины и кодирование по признаку конца содержимого.
Кодирование с явным указанием длины использует следующее преобразование некоторого типа данных:
| Идентификатор | Длина | Содержимое |
Идентификатор представляет собой число, которое задает тип содержимого, а длина содержит в себе длину содержимого. Ниже дана таблица соответствия типов данных и идентификаторов.
| Идентификатор | Тип |
| Структура | |
| Число | |
| Строка | |
| Буфер | |
| Звук | |
| Движение | |
| Цвет | |
| Запах |
Таким образом звук ‘мяу’ будет представлен следующим образом:
| Мяу | ||
| Идентификатор | Длина | Содержимое |
А структура вида {{мяу}{прыгнул}{серый}{}} будет выглядеть:
| мяу | Прыгнул | Серый | |||||||||||
| Звук “мяу” | Движение “прыгнул” | Цвет “серый” | Запах “” | ||||||||||
| Общая структура |
Декодирование будет выглядеть следующим образом:
Считываются два первых числа. Первое из них обозначает тип следующего содержимого, второе - его длину.
Если тип простой (не структура), переходим к следующему пункту, иначе пункту 1.
Считываем в переменную соответствующего типа буфер указанного размера.
Если исходный буфер не пуст, переходим к п. 1.
Собираем целевую структуру с расстановкой необходимых разделителей.
В данном примере это выглядит так:
Считываются два первых числа. Получаем тип - структура, длина - 47.
Считываются два первых числа. Получаем тип - звук, длина - 3.
Считываем в переменную sound 3 байта. В результате переменная sound = “мяу”
Считываются два первых числа. Получаем тип - движение, длина - 7.
Считываем в переменную move 7 байт. В результате переменная move = “прыгнул”
Считываются два первых числа. Получаем тип - цвет, длина - 5.
Считываем в переменную color 5 байт. В результате переменная color = “серый”
Считываются два первых числа. Получаем тип - запах, длина - 0.
Считываем в переменную smell 0 байт. В результате переменная smell = “”
Исходный буфер пуст, переходим к составлению целевой структуры.
Пусть в целевой структуре разделитель квадратная скобка ([]), тогда она равна [[+$sound+][+$move][+$color][+$smell]] или [[мяу][прыгнул][серый][]].
Таким образом структура {{мяу}{прыгнул}{серый}{}} преобразована в [[мяу][прыгнул][серый][]].
Кодирование по признаку конца содержимого имеет следующий вид:
| Идентификатор | Содержимое | Признак конца содержимого |
В силу ограничений интерпретатора в качестве признака конца содержимого использовать два нулевых байта, как это рекомендуется МОС, нельзя, поэтому используйте любые другие комбинации, например “255”.
Таким образом звук ‘мяу’ будет представлен следующим образом:
| Мяу | ||
| Идентификатор'd1пf'e4пf'f0пf'e8мое | Признак конца содержимого |
А структура вида {{мяу}{прыгнул}{серый}{}} будет выглядеть:
| Мяу | прыгнул | Серый | |||||||||||
| Звук “мяу” | Движение “прыгнул” | Цвет “серый” | Запах “” | ||||||||||
| Общая структура |
Таким образом, благодаря механизмам уровня представления (т.е. согласованию синтаксисов, кодированию и т.д.) на приемном конце принятые данные всегда будут трактоваться однозначно и верно, несмотря на различие абстрактных синтаксисов систем. Это происходит благодаря перекодировки данных в синтаксис передачи, который одинаков (в течении одного сеанса связи) для обоих систем.
3. Фрагменты реализации протокола уровня представления на лабораторном комплексе.
Основной задачей уровня представления в рамках данной части ДЗ является согласование контекста представления и преобразование (в обе стороны) между абстрактным синтаксисом и синтаксисом передачи. Служба представления содержит три фазы: установления соединения, передачи данных, освобождения соединения. В целях упрощения задачи из службы представления изъяты услуги управления контекстами.
В фазе установления соединения предусмотрена одна услуга, P-CONNECT.
Пример простейшей организации услуги P-CONNECT без каких-либо параметров:
Обработка события P_CONNECT.REQ:
down S_CONNECT.REQ address $sysB
Обработка события S_CONNECT.IND:
up P_CONNECT.IND
Обработка события P_CONNECT.RESP:
down S_CONNECT.RESP address $sysA
Обработка события S_CONNECT.CONF:
up P_CONNECT.CONF
где sysB - адрес вызываемой системы, а sysA - адрес вызывающей системы.
При установлении соединения системы должны договориться об используемом контексте. Это необходимо для того, чтобы системы “говорили” на одном языке. В случае отсутствия такой договоренности на приемном конце вместо полезной информации получится информационный мусор. Как, например, при открытии текстового файла в 866-ой кодировке с помощью 1251-ой. Механизм, используемый при этом, может быть похож на механизм, используемый сеансовым уровнем при установлении защиты с небольшими изменениями. Такой механизм описан в предыдущей части ДЗ. Он обеспечивает передачу служебных данных после установления сеансового соединения перед индикацией соединения уровня представления. Изменения заключаются в том, что инициирующая система посылает ведомой все возможные варианты синтаксиса передачи, а выбирает среди них тот, который возможен так же с её стороны и отсылает его обратно.
Фаза передачи данных включает в себя средства передачи информации и управления диалогом.
Средства передачи информации позволяют пользователям обмениваться информацией и включают в себя услугу P-DATA, которая и производит преобразование между абстрактным синтаксисом и синтаксисом передачи. Правила кодирования описаны в предыдущем пункте (п. 2). В примере ниже используется кодирование с явным указанием длины, при этом структура имеет укороченный вид (только два поля), на передающем конце использует в качестве разделителя знак фигурные скобки ({}), а на принимающем - знак квадратные скобки ([]) и имеет вид {{звук}{движение}}. Все различие между абстрактными синтаксисами на обоих концах сводится к различиям в разделителях при описании структур. Используемый способ кодировки и разделители согласовываются ранее в процессе установления соединения при согласовании контекстов.
Обработка события P_DATA.REQ:
;datatype - тип данных (число)
; clbrack - закрывающий символ-разделитель (строка длиной 1) (в примере “}”)
unbuffer userdata datatype 4 s sizeof(userdata)-4 определить тип данных
if $datatype == 1 struct структура
if $datatype == 2 number число
if $datatype == 3 string строка
if $datatype == 4 buff буфер
goto send1
number:
buffer buf 12 2 4 4 4 $s 4
goto send1
string:
buffer buf sizeof(s)+8 3 4 sizeof(s) 4 $s 4
goto send1
buff:
buffer buf sizeof(s)+8 4 4 sizeof(s) 4 $s 4
goto send1
struct:
;пусть userdata содержит структуру {{мяу}{прыгнул}{серый}{}}
;подготовка буфера (перевод строки в буфер и удаление двух первых символов, т.е. символов “{{”)
;s содержит “{{мяу}{прыгнул}}”
unbuffer s c 2 t sizeof(s)-2 t содержит “мяу}{прыгнул}}”
;извлечение переменных соответствующих типов
unbuffer t sound pos($clbrack,t)-1 c 2 s sizeof(t)-2-$q s содержит “прыгнул}}” sound содержит “мяу”
unbuffer s move pos($clbrack,s)-1 c 2 t sizeof(s)-2-$q t содержит “” move содержит “прыгнул”
;кодирование переменных соответствующих типов
buffer bufsound sizeof(sound)+8 10 4 sizeof(sound) 4 $sound sizeof(sound) bufsound содержит “10 3 мяу”
buffer bufmove sizeof(move)+8 20 4 sizeof(move) 4 $move sizeof(move) bufmove содержит “20 7 прыгнул”
;расчет размера окончательного буфера
set q sizeof(bufsound)+sizeof(bufmove)
;приготовление окончательного буфера
buffer buf $q+8 1 4 $q 4 $bufsound sizeof(bufsound) $bufmove sizeof(bufmove)
;buf содержит ”1 26 10 3 мяу 20 7 прыгнул”
goto send1
send1:
down S_DATA.REQ userdata $buf
goto exit
Событие T_DATA.IND:
; clbrack - закрывающий символ-разделитель (строка длиной 1) (в примере “]”)
; opbrack - открывающий символ-разделитель (строка длиной 1) (в примере “[”)
;определение типа и длины буфера (type - тип; len - длина)
unbuffer userdata type 4 len 4 buf sizeof(userdata)-8
if $type == 1 struct1
if $type == 2 number1
if $type == 3 string1
if $type == 4 buff1
goto exit
number1:
unbuffer buf num $len
buffer data 8 2 4 $num 4
out $num
goto send
string1:
unbuffer buf str $len
buffer data sizeof(str)+4 3 4 $str sizeof(str)
out $str
goto send
buff1:
unbuffer buf buff $len
buffer data sizeof(buff)+4 4 4 $buff sizeof(buff)
goto send
struct1:
;userdata -”1 26 10 3 мяу 20 7 прыгнул”
; type - 1 len - 26 buf -”10 3 мяу 20 7 прыгнул”
next:
if sizeof(buf)==0 done
unbuffer buf type 4 len 4 buf1 sizeof(buf)-8 type - 10 len - 3 buf1 -”мяу 20 7 прыгнул”
if $type==10 sound
if $type==20 move
goto error
sound:
unbuffer buf1 ssound $len buf sizeof(buf1)-$len ssound - ”мяу” buf - ”20 7 прыгнул ”
goto next
move:
unbuffer buf1 smove $len buf sizeof(buf1)-$len smove - ”прыгнул” buf - ” ”
goto next
error:
out "неизвестный тип"
goto exit
;приготовление окончательного буфера
done:
set str $opscob+$opscob+$ssound+$clscob+$opscob+$smove+$clscob+$clscob str - “[[мяу][прыгнул]]”
buffer data sizeof(str)+4 1 4 $str sizeof(str)
goto send
send:
up P_DATA.IND userdata $data
exit:
Средство управления диалогом дает возможность распределять маркеры, управлять синхронизацией и ресинхронизацией. Использует следующие услуги: для управления расположением маркеров услуги P-GIVE-TOKENS, P-PLEASE-TOKENS, P-GIVE-CONTROL и для фиксации точек синхронизации и ресинхронизации услуги P-SYNC-MINOR, P-SYNC-MAJOR, P-RESYNCHRONIZE. Эти услуги отображаются на соответствующие сервисы сеансового уровня, и поэтому их реализация проста. Например:
Обработка события P_SYNC_MAJOR.REQ:
down S_SYNC_MAJOR.REQ
Фаза завершения сеансового соединения характеризуется тремя услугами: S-RELEASE - упорядоченное завершение, S-P-ABORT и S-U-ABORT - безусловное завершение. Эти услуги отображаются на соответствующие сервисы сеансового уровня так же, как и услуги средств управления диалогом.
1. Прикладной уровень.
1.1 Общие положения.
Прикладной уровень является последним (седьмым) уровнем ЭМВОС. С этим связан ряд особенностей, отличающих его от других уровней эталонной модели. На прикладном уровне завершается наращивание сервисной мощности модели ВОС по архитектурной вертикали и начинается своего рода горизонтальное наращивание. Сервис, поставляемый различными протокольными прикладными объектами с учетом определенных ограничений, можно объединять, формируя различные профили сервиса прикладного уровня в интересах конкретных специальных прикладных систем.
На прикладном уровне осуществляется окончательное и естественное погружение механизмов взаимосвязи, объявленных в модели, в вычислительную среду с ее понятийным построением. Очевидна поэтому потребность в уточненном описании понятия прикладного процесса (application process, AP). Прикладной процесс - это идентифицируемый объект в рамках реальной открытой системы, ведущий обработку информации и ответственный за согласование правил среды своего существования с законами модели ВОС. Прикладной процесс представляется в рамках модели ВОС одним или более прикладными объектами (Application Entity, AE).
Прикладной объект, далее, представляется совокупностью элементов прикладных служб (Application Service Elements, ASE). Такая совокупность, в свою очередь, может быть разделена на набор общих элементов прикладных служб (ОЭПС, ACSE), некоторый набор специальных элементов прикладных служб (СЭПС, SASE), а также элемент, создаваемый разработчиком прикладной системы - элемент пользователя (ЭП, UE), рис.1.1.1.
Целью выделения общего прикладного сервиса в отдельный стандарт является обеспечение разработчиков прикладных распределенных систем обработки информации наиболее общими унифицированными услугами, которые в совокупности с услугами представительного уровня составляют понятийную основу построения и работы приложений.
В наборе общих элементов прикладных служб (ОЭПС) имеется элемент службы управления ассоциацией (ЭСУА) - множество функций, обеспечивающих минимальные требуемые услуги службы прикладного уровня. Прикладная ассоциация устанавливается между двумя вызовами прикладных объектов при необходимости обмена информацией между прикладными объектами с целью выполнения задания по распределенной обработке информации.
Свойства и цель информационного обмена по прикладной ассоциации определяются в зависимости от устанавливаемого для нее контекста обработки информации и прикладного контекста. Первый определяется конкретным заданием по распределенной обработке информации, для которого установлена ассоциация. Прикладной контекст формируется явно определенным набором элементов прикладной службы, которые могут быть вызваны пользователем ассоциации.
Каждый элемент прикладной службы требует описания предоставляемых им услуг и поддерживающего их выполнение протокола.
Спецификация протокола задает правила информационного обмена между равноправными элементами прикладной службы. Она также может содержать описани