Процедуры обработки аномальных ситуаций, относящихся к операциям

Рассматриваются следующие аномальные ситуации:

- никакой реакции на вызов операции класса 2;

- прием некорректно сформированной компоненты – тип компоненты и/или идентификатор вызова не могут быть распознаны (т.е. не идентифицируется состояние конечного автомата)

- корректный прием компоненты, но в нарушение допустимой последовательности переходов

Действия, предпринимаемые компонентным подуровнем для доклада об ошибках в части компонент, представлены в таблице 5. При осуществлении выборов, указанных в таблице, руководствуются следующим:

- когда ошибка протокола обнаружена местным ТС пользователем, этот ТС пользователь далее не информируется посредством ТС-Reject, т.к. он уже знает о ее существовании

- в других случаях (неприем компонентным подуровнем), местному ТС пользователю всегда рекомендуется ввести примитив управления диалогом (см. механизм неприема, описанный ниже)

- когда компонента не принята, соответствующий конечный автомат состояний переходит в исходное состояние

- механизм неприема (компоненты) действует всегда, когда это является возможным, даже если идентификатор вызова не присвоен или не распознан (состояние конечного автомата подуровня компонент не может быть идентифицировано), механизм неприема (rejection) должен быть инициирован. Единственным исключением является случай, когда неприему подлежит сама компонента reject.

Об ошибках протокола в компонентной части сообщения ТСАР, сообщается посредством использования компоненты reject. Компонента reject. Передается как отклик на некорректную компоненту, отличную от самой компоненты reject.

Когда идентификатор вызова (Invoke Id), имеющийся в компоненте подлежит удалению (reject), этот идентификатор отражается в компоненте reject.

Сокращения типов компонент представлены выше. В случае, если в сообщении содержится множество компонент и одна из них обнаружена компонентным подуровнем, то все последующие компоненты, содержащиеся в сообщении, удаляются из системы.

Действия, предпринимаемые при ошибках протокола в части компонент

Местные					Удаленные (прим.)
Принятый тип компоненты	Тип ошибки	Местные действия	Конечный автомат компоненты	Рекомендации местным пользователям	Конечный автомат компоненты	Рекомендации удаленным пользователям
Invoke	Syntax error or invalid linked id. (valid invoke id.)	Initiate Reject	NA	Yes	Return to Idle	Yes
	Syntax error ( invalid inv. id.)	Initiate Reject	NA	Yes	No action	Yes
Return result (L/NL) or return error	Syntax error ( invalid inv. id.)	Initiate Reject	Return to Idle	Yes	NA	Yes
	Syntax error ( invalid inv. id.)	Initiate Reject	No action	Yes	NA	Yes
Return result (L/NL)	Operation class 2/4	Initiate Reject	Return to Idle	Yes	NA	Yes
Return error	Operation class 3/4	Initiate Reject	Return to Idle	Yes	NA	Yes
Reject	Syntax error	Initiate Local Reject	No action	Yes	NA	No
Unknown	Syntax error	Initiate Reject	NA/No action	Yes	NA/No action	Yes

N/A – не принимается

а) рекомендуется оповещение ТС пользователя, так чтобы он мог бы ввести примитив управления диалогом, чтобы послать компоненту reject, сформированную компонентным подуровнем

в) невозможно определить существует ли конечный автомат вызова или нет, и, таким образом, никаких действий не предпринимается

Note: Какие-либо действия на удаленном окончании зависят от местного пользователя, вводящего примитив диалога, чтобы послать компоненту reject, сформулированную местным CSL. Некоторые пользователи могут выбрать - не вводить диалоговый примитив в некоторых или всех случаях. В этих случаях на удаленном окончании не предполагается никаких действий.

Неприем какой-либо части сегментированного результата эквивалентно неприему всего результата. Соответствующий конечный автомат переходит в исходное состояние. Последующие части аналогичного переданному ранее конечного результата, также должны быть не приняты (на базе пассивного конечного автомата). Механизм неприема, при обнаружении компонентным подуровнем ситуации (не на местном уровне), где должен быть инициирован “неприем”, компонентный подуровень образует компоненту reject, сохраняет ее и информирует местного ТС пользователя посредством примитива индикации TC-L-Reject. ТС пользователь может далее принять следующие решения:

а) продолжить диалог

в) закончить диалог, используя базовый сценарий

с) прервать диалог

В случаях а) и в) первый примитив управления диалогом (запрос TC-Continue или TC-END, соответственно), введенные пользователем ТС, переключают передачу сохраненных компонент «reject», образованных для этого диалога компонентным подуровнем. Удаленный подуровень компонент принимает компоненты reject, образованные для этого диалога, освобождает соответствующие конечный(е) автомат(ы) состояний компонентного подуровня, если это возможно (согласно таблице 5) и информирует ТС пользователя удаленного неприема посредством примитива (примитивов) информации «TC-R-Reject».

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

Обработка аномальных ситуаций, связанных с операциями

Процедуры подуровня транзакций

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

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

Подуровень транзакций обрабатывает часть транзакции (тип сообщения и идентификатор транзакции) сообщения ТСАР. Идентификаторы транзакции идентифицируют транзакцию. Каждое окончание присваивает местную идентификацию транзакции, как указывается в Рекомендациях Q.773, эти локальные идентификаторы транзакции передаются в транзакционный части сообщений.

Компонентная часть сообщения ТСАР передается между компонентным подуровнем и транзакционным подуровнем как пользовательские данные в примитивах подуровня транзакций. В случае неструктурированного диалога, идентификатор транзакции не присваивается. Компонентная часть сообщения Unidirectional принимается как пользовательские данные в примитиве запроса TR-UNI. Часть транзакции сообщение Unidirectional формируется, после чего производится передача сообщения.