ГОСТ Р 54708—2011
- начало обработки: идентификатор известен и обработка может технически быть выполнена, произвольно,
дополнительно представленные данные, связанные с командой, находятся в разрешенных пределах (контент
относится кобщему подтверждению);
- конец обработки: команда окончательно выполнена (контент относится копределенному подтверждению).
Дополнительный TAG элемент состояния (часть данных команды)может предоставить информацию об успехе или
неудаче.
Определение и использование всехдругихфлагов определяется приложением, использующим DCP структу
ру для двунаправленной связи.
П р и м е ч а н и е —
Л
юбое приложение, использующее эту DCP структуру для двунаправленной связи, дол
жно. по крайней мере, поддерживать подтверждение приема. Поддержка и точное значение других двух стандарти
зированных флагов могут изменяться от приложения к приложению, однако они должны соответствовать значени
ям. указанным выше.
Е.2.4 Данные команды
Данные команды — необходимая информация, чтобы обработать текущее сообщение. Это может быть зна
чение параметра, требуемоедля конкретной команды в пределах отосланного сообщения запроса, значение, кото
рое возвращено внутри ответного сообщения транзакции выборки, или доставки данных клиенту, который на них
предварительно подписался.
Дополнительная секция данных команды пакета сообщения может нести а себе значение или полный TAG
пакет. Наличие, расположение и содержание этого поля зависят от приложения и конкретного идентификатора
команды (см. Е.2.4.1).
Кроме того, данные соответствующей команды могут также переноситься а верхнем иерархическом уровне
сообщения DCP пакета, например, чтобы поддержать совместимость подписки данных доставки (см. Е.2.4.2).
Е.2.4.1 Поле данных команды, несущее полный TAG пакет
Если поле данных команды несет полный TAG пакет, оно может использоваться, чтобы транспортировать
параметры, связанные с конкретным идентификатором команды, или транспортировать любую другую форму
информации. Определение TAG элементов, содержащееся в TAG пакете, приложением, использующим DCP
структурудля двунаправленной связи, может также зависеть от значения идентификатора команды.
Однако некоторые TAG элементы (таблица Е.2)предопределены в настоящем пункте.чтобы обеспечить еди
нообразное решение для кодирования данных общего назначения (применяется, только если поле данных коман ды
несет полный TAG пакет).
Т а б л и ц а Е.2 — TAG элементы
TAG название
TAG значение
О писание
*sta
2 байта «индикатор состояния >♦
п байтов описания состояния:
«индикатор состояния»:
4 бита — класс состояния *
12 битов —
КОД СОСТОЯНИЯ
Эти TAG элементы несут информацию о статусе, напри
мер как ответ на команду (успех/неудача и т. д.);
описание состояния — простой форматированный текст
UFT-8;
класс состояния:
0 = ОК (хорошо);
1 — предупреждение;
2 — ошибка.
3 — 14: специальное применение:
15: неопределенный/неизвестный,
код состояния: специальное применение
*rqu
m байтов
Формат идлина определяются конкретным приложением
и зависят от идентификатора команды
’rsp
р байтов
Формат идлина определяются конкретным приложением
и зависят от идентификатора команды
ТAG элементы "*rqu“ и "гвр" могут использоваться для транспортировкидополнительной информации,отно
сящейся к подписке или сообщению ответа соответственно.
Е.2.4.2 Связанные данные команды в главном уровне иерархии пакета сообщения
В некоторых случаях целесообразно передавать информацию в главном уровне иерархии DCP пакета сооб
щения.
Примерэтого — MDI поток,предварительноподписанный на Клиента итеперь доставленныйСервером: что
бы быть обработанным стандартным декодером MDI. фактические данные MDI должны быть расположены в глав
ном уровне иерархии. Эти данные MDI только сопровождаются с сообщением доставки.
28