JR/T 0066.3-2019Interbank market information exchange protocol - Part 3: Presentation streaming layer (English PDF)

3.1 IMAST protocol framework

The application mode of the flow-fit presentation layer is shown in Figure 1.

Figure 1 Application mode diagram of flow adaptation layer

The IMAST protocol framework relies on the template pointed to by the message to encode and decode to form an IMAST stream for network transmission.

A template is a codec control structure for an IMIX message.

Algorithms and binary code representation methods to control the encoding and decoding of binary streams corresponding to application messages. A template contains several domain pointers Order.

The domain directive specifies the encoding of domains, components, and repeating groups in a message. Domain directives are grouped by name, application type, presence attribute, and operator to make.

The application type is the manifestation of the domain, component, or repeating group in the message at the appropriate flow presentation layer.

3.2 Overall structure of IMAST stream

The overall structure of the IMAST stream is defined using Extended Backus Normal Form (EBNF) syntax.

stream .. = message * | block * block .. = BlockSize message .. = segment * .. = PresenceMap TemplateIdentifier? (field | segment) * field .. = integer | string | Decimal | ByteVector the overall structure of IMAST is shown in Figure 2.

IMIX message

35 = 8 \u003cSOH\u003e Stream-adaptive coding IMAST stream Streaming decoding IMIX message 35 = 8 \u003cSOH\u003e template Domain directive Application Type template Domain directive Application Type

Figure 2 Overall structure of IMAST stream

The overall structure of the IMAST stream is described as follows.

a) stream. An IMAST stream is a sequence of messages, or a sequence of blocks;

b) Block. A block is a sequence containing a single or multiple messages. A block has a leading and is used to represent the block contains the block size in bytes of the message;

c) Message. each message is represented by a segment (ie, a message segment);

d) Segment. A segment consists of a header and a specific field.

An example of an IMAST stream is as follows.

An example of a market data request IMIX message is shown in Figure 3.

Figure 3 Example of market data request IMIX message

After encoding, the market data request IMAST stream is formed, where PAMP represents a placeholder map and TID represents a template identifier, as shown in Figure 4.

Message

Message

Segment

Message

Message

Message

Message

BlockSizeMessage

Message

Message

Message

Message

Message

Message

Placeholder map

PresenceMap

Template identifier

TemplateIdentifier (optional) Field Field Subsection Segment Subsection Segment head BlockSizeMessage BlockSizeMessage 8 = IMIX.2.0 \u003cSOH\u003e 9 = 41 \u003cSOH\u003e 34 = 2 \u003cSOH\u003e 35 = V \u003cSOH\u003e 49 = CFETS-RMB-CSTP \u003cSOH\u003e 56 = IH \u003cSOH\u003e 52 =.20151208-12. 00. 00 \u003cSOH\u003e 263 = 2 \u003cSOH\u003e 1 46 = 1 \u003cSOH\u003e 48 = CNY \u003cSOH\u003e 10 = 167 Stream

Figure 4 Example of market data request IMAST flow

3.3 Byte Stop Bit

The IMAST stream is encoded using stop bit encoding rules, that is, each byte in the message has a stop bit. A stop bit encoding the body is a sequence of bytes, where the most significant bit of each byte indicates whether the next byte is real Part of the body.

An example of stop bits is shown in Figure 5.

Note. When the byte is the last byte of the stop bit entity, the stop bit is set to 1.

Figure 5 Example of stop bit

4.1 Overview

The encoding and decoding process depends on the template to which the message points. When encoding, the encoder advances the domains in the original message through the attributes of the domains in the template.

The encoding operation is performed, and a placeholder image is generated according to the rules, thereby outputting the placeholder image and the encoded value to the message binary stream. IMAST reception the end decoder finds a template according to the template identifier in the received message binary stream, and then according to the encoding rules for the domain in the template (mainly by the Operators and placeholders decide encoding) to decode and restore the message before transmission.

Message Example Byte Byte Byte Byte Byte Byte 7th 6th 5th 4th 3rd 2nd place First place 0th Stop bit data bit Stop bit entity 01111111 11111000 10000010 10101001 10000010 11010110 01000011 01000110 01000101

-------- PMAP ----- | --TID --- | --9th domain-| --- 34-- | ---- 35-- | ----- ---------------------01010100 01010011 00101101 01010010 01001101 01000010 00101101 01000011 01010011

------------------------------ 39 ------------------- -----------------------------01010100 11010000 01001001 11001000 10000000 00110010 00110000 00110001 00110101

----------------- | ------- 56 -------- | --length-- | --------- -------------------------00110001 00110010 00110000 00111000 00101101 00110001 00110010 00111010 00110000

-------------------------- 52 ----------------------- -----------------------------00110000 00111010 00110000 10110000 10000010 10000001 01000011 01001110 11011001

------------------------------------ | --- 263-- | --- 146-- | --------- 48 -------------- |

4.2 Application Type

Application types can be mapped to the following models.

a) Basic types. including integer types, decimal types, string types, and byte vector types;

b) component type. a collection of unordered domain instructions;

c) Repeating group type. a set of domain instructions containing several component types of length and order.

The application type model is shown in Figure 6.

Figure 6 Application type model diagram

4.3 Templates

4.3.1 Overview

The definition of the template should be expressed in XML, by " \u003ctd.template\u003e Element definition. A template-defined XML document can contain a single Template or collection of multiple templates. The template collection should be encapsulated in " \u003ctd.templates\u003e "Element, which can be applied to the entire package Namespace parameter for your template collection.

4.3.2 Grammar rules

The template syntax rules are defined as follows.

start = templates | template templates = element templates {nsAttr?, templateNsAttr?, dictionaryAttr?, template *} = element template {templateNsName, nsAttr?, dictionaryAttr?, instruction *} = field Note.

templates. multiple templates;

template. a single template;

element templates. multiple template elements;

Application Type

basic type

template

-Template name

-Template identifier Decimal field instruction Integer field instructions String field directive Byte Vector Field Instructions Component domain instructions Repeating Group Field Instructions Decimal type Integer type String type Byte vector type Component type Repeating group type element template. a single template element;

nsAttr ?. namespace attribute, optional element;

templateNsAttr ?. template namespace attribute, optional element;

dictionaryAttr ?. dictionary attribute, optional element;

template *. N templates;

templateNsName. template namespace name;

instruction *. N domain instructions.

Example.

The following XML snippet is an example of a template definition in a specific syntax format.

\u003ctemplates xmlns=\"http.//imix.chinamoney.com.cn \" templateNs = "http.//imix.chinamoney.com.cn/ns/templates/sample" ns = "http.//imix.chinamoney.com.cn / ns/IMIX " > \u003ctemplate name=\"MarketDataIncrementalRefresh\"\u003e \u003cstring name=\"BeginString\" id=\"8\"\u003e \u003cconstant value=\"IMIX.2.0\"/\u003e \u003c/string\u003e \u003cstring name=\"MessageType\" id=\"35\"\u003e \u003cconstant value=\"X\"/\u003e \u003c/string\u003e \u003cstring name=\"SenderCompID\" id=\"49\"\u003e \u003ccopy/\u003e \u003c/string\u003e \u003cuInt32 name=\"MsgSeqNum\" id=\"34\"\u003e \u003cincrement/\u003e \u003c/uInt32\u003e \u003csequence name=\"MDEntries\"\u003e \u003clength name=\"NoMDEntries\" id=\"268\"/\u003e \u003cuInt32 name=\"MDUpdateAction\" id=\"279\"\u003e \u003ccopy/\u003e \u003c/uInt32\u003e \u003cstring name=\"MDEntryType\" id=\"269\"\u003e \u003ccopy/\u003e \u003c/string\u003e \u003cstring name=\"Symbol\" id=\"55\"\u003e \u003ccopy/\u003e \u003c/string\u003e \u003cstring name=\"SecurityType\" id=\"167\"\u003e \u003ccopy/\u003e \u003c/string\u003e \u003cdecimal name=\"MDEntryPx\" id=\"270\"\u003e \u003cdelta/\u003e \u003c/decimal\u003e \u003cdecimal name=\"MDEntrySize\" id=\"271\"\u003e \u003cdelta/\u003e \u003c/decimal\u003e \u003cuInt32 name=\"NumberOfOrders\" id=\"346\"\u003e \u003cdelta/\u003e \u003c/uInt32\u003e \u003cstring name=\"QuoteCondition\" id=\"276\"\u003e \u003ccopy/\u003e \u003c/string\u003e \u003cstring name=\"TradeCondition\" id=\"277\"\u003e \u003ccopy/\u003e \u003c/string\u003e \u003c/sequence\u003e \u003c/template\u003e \u003c/templates\u003e

4.3.3 Identifiers

The template identifier in the header of the segment in the data stream indicates the template used by the message, represented by an unsigned integer. If ever Long, a reportable error [ERR R6] is generated.

If a decoder cannot find the template associated with the template identifier present in the data stream, a dynamic error [ERR D9] is generated.

The template identifier is encoded in the same way as the copy operator. Copy operator uses global dictionary and has all template identifier fields A common internal key (Key). See 4.6.7 for the definition of the copy operator.

4.3.4 Name

4.3.4.1 Defining rules

The definition of a template name consists of two parts. the namespace URI and the local name.

The namespace URI using the application type, domain, and operator keywords is specified by the "ns" parameter.

The namespace URI of the template is specified by the "templateNs" parameter.

The local name is specified by the parameter "name".

Both names are the same if and only if their namespace identifier and local name are the same.

4.3.4.2 Syntax specifications

The template name syntax specification is defined as follows.

nsName = nameAttr, nsAttr?, idAttr?

templateNsName = nameAttr, templateNsAttr?, idAttr?

nameAttr = attribute name {token} nsAttr = attribute ns {text} templateNsAttr = attribute templateNs {text} idAttr = attribute id {token} Note.

nsName. namespace name;

nameAttr. name attribute;

nsAttr ?. namespace attribute, optional element;

idAttr ?. identifier attribute, optional element;

templateNsName. template namespace name;

templateNsAttr ?. template namespace attribute, optional element.

4.3.5 Instructions

A template instruction is a sequence of instructions. The instruction should correspond to the position of the data in the stream.

The template instruction mainly uses the domain instruction, which specifies the method of instance encoding and binary stream of the domain.

4.4 Context

The context specifies the operating environment for encoding and decoding, which should include.

a) a collection of templates;

b) current template;

c) a collection of domain instructions;

d) current domain directive;

e) dictionary collection;

f) Optional initial value.

The current template refers to the template being processed. The current template is updated when a template identifier is processed in the stream. References to static templates it can also cause changes to the current template.

4.5 Domain instructions

4.5.1 Definition

A domain directive consists of a name, an application type, an existence attribute, and an operator.

Domain directives are distinguished by name, which is unique within a single component.

The application type specifies the basic encoding method of the field, including. integer field, decimal field, decimal field, ASCII string (asciiStringField), Unicode string (unicodeStringField), byte vector (ByteVectorField), repeat group (sequence), component (group).

The existence attribute is used to indicate whether the domain directive is mandatory or optional. If the attribute is not If specified, the domain instruction is required.

Domain operators are optional information used to specify optimized transmission methods for encoding domain instructions. Domains other than component domain and repeating group domain can be defined its domain operator.

4.5.2 Null Property

The application type of each domain directive has a property of nullability. If the type is nullable, then NULL values are represented in a special way. If the type is non-nullable, no NULL representation is retained. All Some nullable types are constructed in such a way that NULL is represented by a 7-bit entity value where all bits are 0. When using stop bit encoding, NULL it is represented by 0x80.

Unless explicitly specified, the non-nullable representation is used by default.

4.5.3 Grammar Rules

The domain directive syntax rules are as follows.

field = integerField | decimalField | asciiStringField | unicodeStringField | byteVectorField | sequence | group fieldInstrContent = nsName, presenceAttr?, fieldOp?

presenceAttr = attribute presence {"mandatory" | "optional"} Note.

integerField. integer field instruction;

decimalField. decimal field instruction;

asciiStringField. ascii code type string field instruction;

unicodeStringField. unicode string field instruction;

byteVectorField; byte vector field instructions;

sequence. repeated group domain instructions;

group; component domain instructions;

nsName. the domain instruction namespace name;

presenceAttr. presence attribute, optional element;

fieldOp. field operator, optional element.

4.5.4 Classification

4.5.4.1 Integer Field Instructions

4.5.4.1.1 Overview

The types of integer domain instructions include 32-bit unsigned integers (uInt32), 32-bit integers (int32), 64-bit unsigned integers (uInt64), 64-bit integer (int64).

Integers are not limited in size in transfer encoding.

All integer domain instructions are expressed using the big endian method, where the bits and bytes are in network byte order.

That is, the high byte is before the low byte, and the high byte is before the low byte.

4.5.4.1.2 Signed Integer Field Instructions

The value of the entity is one's complement [TWOC]. The most significant bit of the entity value is the sign bit.

4.5.4.1.3 Unsigned Integer Field Instructions

The entity value is the binary representation of the integer.

4.5.4.1.4 Grammar rules

The syntax rules for integer field instructions are as follows.

integerField = element int32 {fieldInstrContent} | element uInt32 {fieldInstrContent} | element int64 {fieldInstrContent} | element uInt64 {fieldInstrContent} Note.

integerField. integer field instruction;

fieldInstrContent. field instruction content;

The prefix "int" indicates that the domain is signed, and "uInt" indicates that the domain is unsigned.

4.5.4.1.5 Error occurs

The integer is represented by a stop bit encoding entity. If an integer has 7 or more significant bits removed, the entity value still represents the same integer, the integer is overlong. If an excessively long integer appears in the stream, unless the integer is used as a block size Small, otherwise reportable error [ERR R6] will occur.

If the integer in the data stream is greater than the maximum value of a specific type or smaller than the minimum value of a specified type, a dynamic error [ERR D2] is generated.

See Table 1 for the maximum and minimum values of each integer type.

Table 1 Maximum and minimum values for each integer type

Type Min Max

int32 -2147483648 2147483647 uInt32 0 4294967295 int64 -9223372036854775808 9223372036854775807 uInt64 0 18446744073709551615

4.5.4.1.6 Coding example

The optional positive numbers are defined as follows.

\u003cint32 id="1" presence="optional" name="Value"/\u003e Examples of optional positive encodings are shown in Table 2.

Table 2 Examples of optional positive encodings

Input value local hex/binary IMAST hex/binary 942755 0x0e 0x62 0xa3 00001110 01100010 10100011 0x39 0x45 0xa4 00111001 01000101 10100100 Note. Stop bits are indicated in bold. The sign bit is underlined. The field is optional and the value is non-negative, so it is incremented by one.

The required positive numbers are defined as follows.

\u003cint32 id="1" presence="mandatory" name="Value"/\u003e See Table 3 for examples of mandatory positive numbers.

Table 3 Examples of mandatory positive numbers

Input value local hex/binary IMAST hex/binary 942755 0x0e 0x62 0xa3 00001110 01100010 10100011 0x39 0x45 0xa3 00111001 01000101 10100011 Note. Stop bits are indicated in bold. The sign bit is underlined. The domain is required, so it is not incremented by one.

Optional negative numbers are defined as follows.

\u003cint32 id="1" presence="optional" name="Value"/\u003e Examples of optional negative encodings are shown in Table 4.

Table 4 Examples of optional negative encodings

Input value local hex/binary IMAST hex/binary-942755 0xf1 0x9d 0x5d 11110001 10011101 01011101 0x46 0x3a 0xdd 01000110 00111010 11011101 Input value local hex/binary IMAST hex/binary Note. Stop bits are indicated in bold. The sign bit is underlined. The field is an optional negative number, so it does not increment by one.

The required negative numbers are defined as follows.

\u003cint32 id="1" presence="mandatory" name="Value"/\u003e See Table 5 for examples of mandatory negative numbers.

Table 5 Example of mandatory negative numbers

Input value local hex/binary IMAST hex/binary-7942755 0xff 0x86 0xcd 0x9d 11111111 10000110 11001101 0x7c 0x1b 0x1b 0x9d 01111100 00011011 00011011 10011101

Note 1. In the local hexadecimal/binary, the high value of the leftmost bit is discarded.

Note 2. In IMAST hexadecimal/binary, the stop bit is indicated in bold. The sign bit is underlined. The domain is required, so it is not incremented by one.

The mandatory positive numbers with sign bit extension are defined as follows.

\u003cint32 id="1" presence="mandatory" name="Value"/\u003e See Table 6 for examples of mandatory positive encoding with sign bit extension.

Table 6 Example of mandatory positive encoding with signed bit extension

Input value local hex/binary IMAST hex/binary 8193 0x20 0x01 00100000 00000001 0x00 0x40 0x81 00000000 01000000 10000001 Note. Stop bits are indicated in bold. The sign bit is underlined. Sign bit extension (italic) required to represent a sign. Domain required, because this does not increase by one.

The required negative numbers with signed bit expansion are defined as follows.

\u003cint32 id="1" presence="mandatory" name="Value"/\u003e See Table 7 for examples of mandatory negative coding with sign bit extension.

Table 7 Example of mandatory negative coding with signed bit extension

Input value local hex/binary IMAST hex/binary-8193 0xff 0xdf 0xff 11111111 11011111 11111111 0x7f 0x3f 0xff 01111111 00111111 11111111 Note. Stop bits are indicated in bold. The sign bit is underlined. Sign bit extension (italic) required to represent a sign. Domain is required, Therefore, it does not increase by one.

Unsigned optional integers are defined as follows.

\u003cuInt32 id="1" presence="optional" name="Value"/\u003e See Table 8 for examples of unsigned optional integer codes.

Table 8 Example of unsigned optional integer encoding

Input value local hex/binary IMAST hex/binary null N/A 0x80 0 0x00 0x81 1 0x01 0x82 942755 0x0e 0x62 0xa3 1110 01100010 10100011 0x39 0x45 0xa4 00111001 01000101 10100100 Note. Stop bits are indicated in bold. The field is optional, so it is incremented by one.

Unsigned mandatory integers are defined as follows.

\u003cuInt32 id="1" presence="mandatory" name="Value"/\u003e See Table 9 for examples of unsigned mandatory integer codes.

Table 9 Example of unsigned mandatory integer encoding

Input value local hex/binary IMAST hex/binary 0 0x00 0x80 1 0x01 0x81 942755 0x0e 0x62 0xa3 1110 01100010 10100011 0x39 0x45 0xa3 00111001 01000101 10100011 Note. Stop bits are indicated in bold. The domain is required, so it is not incremented by one.

4.5.4.2 Decimal field instruction

4.5.4.2.1 Overview

The decimal fraction field instruction contains two parts. the exponent part and the mantissa part. The domain instruction has two parts Use a single domain operator as a whole, or use separate operators for both parts. The whole decimal has no operator specified, or only a single Operator, the operation object is treated as a decimal value, which is expressed as a proportional number in the encoding transmission process (Scaled Number).

A scaled number is represented by a mantissa and an exponent.

For efficiency calculations, floating-point numbers use a base-2 exponent, but to support the exact representation of decimal numbers, proportional numbers are used.

The base 10 index.

V = S × B

In the formula.

V--value;

S--mantissa;

B--base number;

E--index.

Among them, the value is obtained by multiplying the mantissa and the exponent power of 10.

A signed number is represented by a signed integer exponent followed by a signed integer mantissa.

If a proportional number is nullable, its exponent can be nullable, but the mantissa cannot be nullable. The scaled number of NULL values is represented by a NULL exponent Show. The mantissa appears in the stream if and only if the ...