ГОСТ Р ИСО/МЭК ТО 10172-99 Информационная технология (ИТ). Передача данных и обмен информацией между системами. Спецификация взаимодействия между протоколами сетевого и транспортного уровней

ПРИЛОЖЕНИЕ В
(справочное)

     
Локальная координация между СТУ в режиме АРТУ

B.1 Общее применение локальной координации

Как отмечалось в разделе 8, функции, обслуживающие СТУ по протоколу ГОСТ Р 34.950/ГОСТ Р 34.951 в режиме АРТУ, могут обладать локальными сведениями о работе соответствующих СТУ по протоколу ГОСТ Р 34.1952 и наоборот. Таким образом те операции, выполнение которых является частным вопросом реализации протокола транспортного уровня и на которые положения раздела 8 не налагают ограничений, например, объем предоставляемого кредита, размер ПБДТ и др., могут при необходимости быть скоординированы между двумя СТУ. Например, кредит, предоставляемый для одного СТУ, может поддерживаться равным кредиту, доступному удаленной ОС в другом СТУ, где может обеспечиваться упрощенное управление буферами в режиме АРТУ (оно может выглядеть как межконцевое управление потоком). Как одна из крайностей, продвигаемые СБДТ можно так тесно скоординировать, что данные в каждом поступающем ПБДТ будут обрабатываться и продвигаться как единое целое, не дожидаясь поступления оставшихся ПБДТ. Если указатели скоординированы и оба СТУ используют класс 4, может оказаться возможным исключить повторное использование контрольной суммы. (На метод, используемый для определения контрольной суммы, никаких ограничений со стороны протокола по ГОСТ Р ИСО/МЭК 8073 не налагается, и в этом случае ее можно определить, запомнив контрольную сумму, применимую к содержимому данного конкретного ПБДТ, исходя из того момента, когда она была обнаружена правильной в поступающем ПБДТ в другой части системы).

Следует, однако, подчеркнуть, что такая координация возможна только в пределах той степени локальной свободы, которая допускается спецификацией протокола транспортного уровня. Например, если было решено скоординировать подтверждения так, чтобы они передавались по одному СТУ только тогда, когда подтвержденные данные уже продвинуты к удаленной ОС и подтверждены ею по другому СТУ, то это может быть ограничено в классе 4 требованием оставаться в пределах локального времени подтверждения. (Было бы, разумеется, хорошо, если бы значение локального времени подтверждения было определено с учетом предполагаемой работы по этому методу и возможной задержки, но, тем не менее, в случае запоздалого поступления подтверждения ПТБ БУС или ПТУС, реализующий класс 4 может оказаться вынужден требованиями ГОСТ Р ИСО/МЭК 8073 передавать подтверждения независимо от этого).

В.2 Использование причин разъединения

Как отмечалось в разделе 8, ситуацией, когда локальная координация соединений в АРТУ может оказаться особенно полезной, является использование параметра "причина" разъединения СТУ.

При наличии достаточного количества локальных сведений и если код причины разъединения одного СТУ равен 9, 1, 2 или 3, уместно использовать тот же самый код причины разъединения в другом СТУ. То же может быть сделано и при кодах 128+1 и 128+7, за исключением использования класса 0, где должно использоваться значение 0. Код причины разъединения 128+2 в соединении по ГОСТ Р 34.950/ГОСТ 34.954 может быть преобразован в код 2 для соединения по ГОСТ Р 34.1952 (не очень близко по существу, но указывает постоянные условия). Другие коды причины разъединения должны приводить к использованию в других соединениях значения 0.

Рекомендуется, чтобы параметр "дополнительная информация" ПБДТ ЗР использовался для указания кода причины разъединения в другом соединении. Однако, если первоначальное разъединение было инициировано оконечной системой и оно само включало параметр "дополнительная информация", который доступен для локальных сведений, предпочтительнее присвоить более высокий приоритет передаче этой первоначальной дополнительной информации и добавить указание причины первоначального разъединения в конец при наличии места.

Текст документа сверен по:
официальное издание
М.: ИПК Издательство стандартов, 1999