ГОСТ Р 54708—2011
Определение и использование всех других флагов определяется приложением, использующим 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 элементы несут информацию о статусе, например как
ответ на команду (успех/неудача и т. д.);
описание состояния — простой форматированный текст UFT-8;
класс состояния:
0 = ОК (хорошо);
1 — предупреждение;
2 — ошибка;
3 — 14: специальное применение;
15: неопределенный/неизвестный;
код состояния: специальное применение
Формат и длина определяются конкретным приложением и за-
висят от идентификатора команды
TAG значениеОписание
*sta2 байта <индикатор состояния > +
n байтов описания состояния;
< индикатор состояния >:
4 бита — класс состояния +
12 битов — код состояния
*rqum байтов
*rspp байтов
Формат и длина определяются конкретным приложением и за-
висят от идентификатора команды
28
TAG элементы “*rqu” и “*rsp” могут использоваться для транспортировки дополнительной информации, от-
носящейся к подписке или сообщению ответа соответственно.
Е.2.4.2 Связанные данные команды в главном уровне иерархии пакета сообщения
В некоторых случаях целесообразно передавать информацию в главном уровне иерархии DCP пакета со-
общения.
Пример этого — MDI поток, предварительно подписанный на Клиента и теперь доставленный Сервером:
чтобы быть обработанным стандартным декодером MDI, фактические данные MDI должны быть расположены в
главном уровне иерархии. Эти данные MDI только сопровождаются с сообщением доставки.
Другой пример — обратно совместимое расширение протоколов, в настоящее время несущих команды и
связанные с командой данные на главном уровне. Любой запрос или ответ (в настоящее время находящиеся на
главном уровне) могут просто дополнительно сопровождаться с отправленным сообщением или сообщением вы-
борки соответственно (один дополнительный TAG элемент на команду). Это переданное сообщение или сообще-
ние выборки использует, например, то же самое название команды, как определено для TAG названия команды
(или идентификатора команды, где это применимо), и добавляет все особенности DCP структуры для двунаправ-
ленной связи без дублирования фактически полезных данных от главного уровня в секцию данных команды со-
общения.