|
US$829.00 · In stock
Delivery: <= 5 days. True-PDF full-copy in English will be manually translated and delivered via email.
JR/T 0182-2020: Light weight real-time STEP message transfer protocol
Status: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| JR/T 0182-2020 | English | 829 |
Add to Cart
|
5 days [Need to translate]
|
Light weight real-time STEP message transfer protocol
| Valid |
JR/T 0182-2020
|
PDF similar to JR/T 0182-2020
Basic data | Standard ID | JR/T 0182-2020 (JR/T0182-2020) | | Description (Translated English) | Light weight real-time STEP message transfer protocol | | Sector / Industry | Finance Industry Standard (Recommended) | | Classification of Chinese Standard | A11 | | Word Count Estimation | 33,329 | | Date of Issue | 2020-02-26 | | Date of Implementation | 2020-02-26 | | Regulation (derived from) | China Securities Regulatory Commission Announcement (2020) No. 15 | | Issuing agency(ies) | People's Bank of China | JR/T 0182-2020: Light weight real-time STEP message transfer protocol---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Light weight real-time STEP message transfer protocol
ICS 03.060
A11
JR
People's Republic of China Financial Industry Standards
Lightweight real-time STEP message transmission protocol
2020-02-26 release
2020-02-26 Implementation
Issued by China Securities Regulatory Commission
Table of contents
Foreword...II
Introduction...III
1 Scope...1
2 Normative references...1
3 Terms and definitions...1
4 Session mechanism...1
4.1 Important notes on key concepts...1
4.2 Session Management...5
4.3 Recovery...6
5 Message Specification...6
5.1 Message structure...7
5.2 Management messages...8
6 Data Dictionary...14
6.1 Data Type...14
6.2 Session layer domain specification...15
Appendix A (Normative Appendix) Calculating Checksum...17
Appendix B (Normative Appendix) Handling Heartbeat and Test Requests...18
Appendix C (Normative Appendix) Login Scenarios...19
C.1 Normal login scenario 1...19
C.2 Normal Login Scenario Two...20
C.3 Normal login scenario 3...20
C.4 Scenario One for Abnormal Login...22
C.5 Abnormal Login Scenario Two...22
Appendix D (Normative Appendix) Handling Session Rejection...24
Appendix E (Normative Appendix) Scenarios for Handling Retransmission Requests...25
E.1 Scenario 1 for handling retransmission requests...25
E.2 Scenario 2 for handling retransmission requests...26
Appendix F (Normative Appendix) Deregistration Scenarios...27
Foreword
This standard was drafted in accordance with the rules given in GB/T 1.1-2009.
This standard was proposed by the Securities Technical Committee of the National Financial Standardization Technical Committee (SAC/TC180/SC4).
This standard is under the jurisdiction of the National Financial Standardization Technical Committee (SAC/TC180).
Drafting organizations of this standard. China Securities Regulatory Commission Information Center, Shanghai Stock Exchange, Shenzhen Stock Exchange, China Securities Regulatory Commission
Information Technology Service Co., Ltd.
The main drafters of this standard. Yao Qian, Liu Tiebin, Zhou Yunhui, Du Juan, Zhu Li, Wang Pengfei, Li Xiangdong.
Introduction
The agreement is the financial information exchange agreement, which is an agreement for electronic financial information interaction between global financial market institutions and participants, hereinafter referred to as the FIX agreement.
1 Scope
This standard specifies a lightweight real-time STEP message transmission protocol
Used session mechanism, message format, security and encryption, data integrity, extension method, message format
Specifications, data dictionary, etc.
This standard is applicable to support the exchange of business data between stock exchanges and market participants and related financial institutions. This standard can also be promoted
It is used to support the session connection between various institutional systems in the securities and futures industry.
2 Normative references
The following documents are indispensable for the application of this document. For dated reference documents, only the dated version applies to this article
Pieces. For undated references, the latest version (including all amendments) applies to this document.
3 Terms and definitions
The following terms and definitions apply to this document.
3.1
Securities trading exchange protocol;STEP
The industry information standard for the exchange of securities transaction data between the stock exchange trading system and the market participant system.
3.2
Financial information exchange; FIX
International information standard for electronic exchange of securities transaction information.
3.3
Fix session layer protocol; FIXT
Electronic data transmission protocol independent of communication protocol (such as TCP, UDP, etc.) and communication medium (such as optical cable, satellite, etc.), FIX protocol
Important sub-agreement.
4 Session mechanism
4.1 Important notes on key concepts
4.1.1 Session layer retransmission
4.1.1.1 This standard specifies the session layer connection standard between the internal system of market participants and the stock exchange through an open interface. This standard
It is a simplified version of the FIXT 1.1 standard of the FIX Standardization Organization, and the use of message tags follows the FIX 5.0 SP2 regulations. due to
JR/T 0022-2014 Securities Trading Data Exchange Protocol is only a localized version of the FIX protocol. To highlight the direct source of the standard, the following abbreviation
Call this standard "LFIXT".
4.1.1.2 Unless otherwise specified, the receivers, senders, and other communication participants mentioned in this standard refer to applications implemented in accordance with this standard.
Application procedures or modules, hereinafter referred to as "LFIXT participants". Programs or modules developed based on FIXT (hereinafter referred to as "FIXT participation
Party”), if you want to communicate with LFIXT participants, you also need to follow the constraints of this standard.
4.1.1.3 Session layer retransmission is a retransmission mechanism specified by the session layer protocol to ensure orderly and lossless transmission of each session layer
news. In the FIXT session layer protocol, the session layer retransmission is initiated by the message receiver when the message sequence number gap is recognized.
The method is to send a message retransmission request to the other party. This standard actually cancels the session layer retransmission of the FIXT session layer protocol.
It still appears as a standard FIXT session layer and can interoperate with the counterparty FIXT participants. Since a single LFIXT session uses a single
A TCP connection is used as the underlying communication mechanism, so within a single TCP connection, every message will be transmitted in an orderly and without loss. Belong to the same
Between successive TCP connections of a session, although there may be session layer message loss, the received session layer message will still be
It has the nature of orderly reception. Because there may be message loss at the session layer under the LFIXT standard, the lost business messages will only be
Retransmission through the application layer to be restored.
4.1.1.4 Like the FIXT protocol, the LFIXT protocol itself does not limit the standard port number used. As a TCP-based session layer protocol,
The port number used by LFIXT is recommended to be in the interval [1024,49151], and the specific value shall be separately agreed by the communication parties in advance.
4.1.2 Application layer retransmission
Since the session layer recovery mechanism of this standard is only for compatibility with the FIXT session protocol, it cannot be used as a true message recovery mechanism.
use. Therefore, it should be restored through a retransmission mechanism agreed by the application layer. The specific mechanism of application layer retransmission is not within the scope of this standard.
4.1.3 NxtIn and NxtOut
Each message sent and received by both parties of the conversation carries a message sequence number. Each end participating in the communication needs to maintain a pair of serial numbers (NxtIn,
NxtOut), NxtIn represents the sequence number of the next expected incoming message, and NxtOut represents the sequence number to be assigned to the next outgoing message.
4.1.4 Session initiator and receiver
4.1.4.1 The establishment of a session requires an initiator and an acceptor. The initiator sends a Logon message first and hopes the other party to respond
For a Logon message, the receiver is the one that waits for the initiator to send the Logon message and respond with the Logon message. meeting
After the session is established, both the initiator and the recipient of the conversation can send and receive messages in both directions. Don’t set the conversation initiator
(Initiator), session acceptor (acceptor) and the sender and receiver of a particular message
Confuse.
4.1.4.2 Similar to the session initiator and the session acceptor, it also defines the logout initiator and logout acceptor, the session reset initiator and the conference
Word resets the concept of the recipient.
4.1.4.3 The FIXT protocol is suitable for various transport layer protocols (such as UDP), so it is impossible to use specific protocols such as TCP sockets.
Transport layer information is used to distinguish which packets belong to the same FIXT session, and because FIXT does not define a specific FIXT session
It is called the "session number" label, and not all messages have a label like username, so the unique identifier for distinguishing FIXT sessions is
And field combination. As a simplified version of the FIXT standard, the LFIXT standard also complies with this requirement.
4.1.4.4 In the FIXT agreement, a single FIXT participant cannot simultaneously maintain two
Conversation. The recommended approach in FIXT is. When a legitimate session already exists,
If one party tries to initiate a new session in the same way, the other party will directly terminate the newly initiated session without sending any Logout message.
The existing session should not be affected. On the other hand, the FIXT agreement does not specify whether different FIXT participants are allowed to hold
The same identified session. Generally speaking, sessions with the same identity on the same server are easier to check for duplicates.
Knowledge conversation is more difficult to achieve duplicate checking, but it is not impossible. When processing incoming login messages, you should use and perform a session check.
The same-identity session must not be affected, but the same-identity session request received later
It may be accepted, but it may also be rejected. The FIXT agreement does not limit it. If the request is rejected, the rejection method will follow the FIXT agreement
If no Logout message is sent back, the TCP connection is directly disconnected. The conversation initiator should be prepared for this situation. LFIXT standard as
The simplified version of the FIXT standard also complies with this requirement.
4.1.4.5 This standard only allows a single session to conduct full-duplex communication through a single TCP connection at the same time.
After determining whether to allow the communication to continue, you can directly use the socket to distinguish the session to which the message belongs, but for the post received from the same socket
The renewal message should still be checked whether the sum is the same as that of the login.
4.1.5 Message sequence number
All messages are identified by a unique session layer message sequence number (that is, a field in the message header). The message sequence number is
When the session starts, it is initialized to 1 in most cases, and continues to increase throughout the session until the session is all over.
By monitoring the continuity of the message sequence number, both parties in communication can identify the message gap and respond, and can connect multiple connections before and after the same conversation
Synchronize between.
The above-mentioned "continuous increment" is for the normal situation. In the following cases, the message received by the receiver may also
Reverse flow occurs, but the reverse flow at this time is not abnormal, but is called "normal reverse flow".
a) The received message is a message and should be ignored at this time, even if there is a reverse flow
Not a mistake
b) The message received is Y, and such messages are indeed allowed to appear, indicating that this is a session layer
pass;
c) When the session sequence number is reset through a message, the received message must be 1, so it may be
flow.
Each session will create a set of independent inbound and outbound sequence numbers, and any party participating in the connection maintains a set for outbound cancellation.
The sequence number sequence of the message, and also maintains another set of independent sequence number sequence of the incoming message to monitor the received message
Serial number to ensure the discovery and processing of information gaps.
After the session is established, when the message sequence number received by the LFIXT protocol implementer is not equal to the expected message sequence number (NxtIn), you need to consider
Consider making corrections. There are several situations here.
a) If the incoming message sequence number does not belong to the normal reverse flow, it indicates that a serious error has occurred, and the conversation should be terminated immediately, and
Start manual intervention;
b) If the incoming message sequence number is a normal reverse flow, it is not an error and should be handled normally;
c) If the sequence number of the incoming message, it indicates that a message has been missed. Because LFIXT uses TCP as the transport protocol, this
This situation indicates that a serious abnormal error has occurred and the current session should be terminated immediately.
4.1.6 Heartbeat
During the idle period of message exchange, both connected parties will generate heartbeat messages at specified time intervals. Communication can be monitored through heartbeat messages
The status of the connection and identify gaps in the sequence number of incoming messages.
The heartbeat interval is determined by the session initiator through the field of the login message. Any message (not just
After the heartbeat message), the heartbeat interval timer should be reset immediately. The heartbeat interval time should be confirmed by both parties of the connection and initiated by the session
It is given by the person and confirmed by the recipient of the conversation.
Both parties should use the same heartbeat interval. Each heartbeat message will occupy a message sequence number.
4.1.7 Ordered message processing
This standard uses TCP connection as the underlying communication mechanism. After the session is established, during the continuation of the same TCP connection, the receiver is sending
When there is a gap in the incoming message, it means that a serious abnormality has been detected in the other party or the communication connection. It is recommended that the receiver terminate the session and disconnect the TCP
connection. If the receiver is the initiator of the session, the session should be re-established as needed.
4.1.8 Possible repeated message transmission
This session protocol uses TCP connection as the underlying communication mechanism. After the two parties of the session establish a TCP connection, they will use the Logon message to perform sequence
Number negotiation is followed by continuous communication based on TCP. Under normal circumstances, there should be no case where the previous message is lost but the next message is received.
Situation, so.
a) When a gap in the sequence number of the incoming message is found, the LFIXT participant should not send a retransmission request, and should directly disconnect after returning Logout
Connect
b) Retransmission requests are allowed in incoming messages. For example, FIXT-based communication counterparties receive the previous message but themselves
Did not save, and expect to be retrieved through retransmission request according to the FIXT session layer protocol. The LFIXT participant will simply return
Send a message to respond;
c) Messages that are allowed to appear in incoming messages, such as FIXT-based communication counterparties have not received their own
Send a retransmission request, but only because it suspects that the party may miss some messages, and send such messages to the party.
According to the FIXT standard, except for messages, other management messages should not be retransmitted in theory, but should be sent with the same
The message with the message sequence number and the flag replaces the original message. In the process, was replaced
Although the message itself still appears with the same message sequence number and with the same set flag,
It is also interpreted by the FIXT standard as "replacement" rather than "retransmission".
4.1.9 Possible repeated message sending
In this standard, the application layer retransmission flag should be clearly set in the application layer protocol, and should not be reflected in the session layer message flag bit
on. Since the counterparty of the interoperability should comply with the same application layer protocol, this standard will not give any information to the message.
This standard allows the PossibleResend flag to appear in the incoming message header, but this flag will be ignored, and messages without this flag will be directly removed.
Information is handled by the application layer.
4.1.10 Message integrity
The integrity of the message data content can be verified in two ways. verify the message length and a simple checksum of characters.
The length of the message is included in the field, which can be counted after the field in the message, until the package
Include the domain delimiter that appears directly before the CheckSum domain number ('10=')\u003cSOH\u003e Between the characters to verify.
The method of verifying the checksum is. starting from the '8' in the '8=' in the message header, up to and including the domain number directly before it
appeared\u003cSOH\u003e Character, after adding up the binary value of each character, compare the lowest 8 bits of the calculated value with the value in the field.
4.1.11 Confusing news
A message is called "confusing" when at least one of the following situations occurs.
4.1.12 Message confirmation
Since this standard is based on an optimistic message transmission mode, gaps are found by monitoring the message sequence number, and it does not support the confirmation of each message
recognize. However, the confirmation of a large number of message sending and receiving can be defined at the application layer and accepted or rejected at the application layer.
4.1.13 Encryption
The LFIXT session layer does not encrypt data. Both parties in the session can consider using the encryption mechanism of the communication layer, such as using TCP
TLS communication encryption mechanism above.
4.2 Session Management
4.2.1 Session and connection
This standard uses TCP connection as the underlying communication mechanism.
If the LFIXT participant is the active initiator of the session, the flag should be reset by setting the sequence number after each new TCP connection
Logon message to reset the initial message sequence number back to 1.At this time, there is a one-to-one correspondence between the session and the TCP connection.
Although this standard can be designed to use two independent TCP connections at the bottom level, and each connection works in simplex mode, because the TCP
Realizing full-duplex communication on the connection is not difficult and simple to maintain. Therefore, this standard stipulates. For a single session, only one
Full-duplex TCP connection.
If the LFIXT participant is the receiver of the session, since the initiator of the session may be a standard FIXT, the established session can be
Spanning multiple TCP connections.
Within a single TCP connection, each session is divided into three parts. session establishment, message exchange, and session termination.
4.2.2 Establish a session
4.2.2.1 Session steps
Establishing a session includes three internal steps. connection establishment, identity authentication, and message synchronization.
4.2.2.2 Establish a connection
The initiator and receiver of the session should first establish a TCP connection. LFIXT participants should always initialize after the TCP connection is established.
4.2.2.3 Identity authentication
The session initiator sends a login message (Logon), and the session acceptor verifies the legitimacy of the initiator's identity. The processing logic is as follows.
a) If the identity of the initiator is authenticated, the recipient sends a login message in response.
b) If authentication fails, the recipient of the session may optionally send a logout message (Logout) with a failure description and then close the connection.
Sending a logout message is not necessary, because doing so will consume a serial number, which may cause other problems in some cases.
c) The conversation initiator should wait for the confirmation Logon message from the recipient before sending other messages to the recipient. Otherwise, the recipient
It may not be ready to receive them.
d) After the initiator is authenticated, the recipient will immediately respond with a confirmation Logon message. The initiator will send the Logon returned from the recipient
The message serves as confirmation that "a session has been established".
4.2.2.4 Message synchronization
This standard does not provide a real session layer retransmission mechanism, so when the LFIXT participant is the initiator of the session, it can be reset through the session
The message resets the message sequence numbers of both parties in the conversation to complete the session layer message synchronization.
When the LFIXT participant is the receiver of the session, it can use the Logon message to complete the session layer cancellation
Information synchronization. This method provides compatibility with the message synchronization of the FIXT session protocol. For the specific mechanism, see 4.3.2 Login Message Processing.
4.2.3 Message Exchange
After the session is established, the two parties in the session can begin normal message exchange. The messages exchanged include "management messages" and "applications
Message", this standard only describes management messages.
4.2.4 Logout session
The normal end of the LFIXT session is to send a logout message (Logout) to each other through the connection parties, and there is no need to make a message gap when logging out
an examination. If the logout message (Logout) is not received at the end, the other party will be regarded as logged out. In addition to other ways of meeting
The end of the conversation is considered abnormal and should be handled as an error.
Before ending the session, the initiator of the logout message (Logout) should wait for the logout message (Logout) sent back by the other party. If received
If the party does not reply within a certain period of time, the conversation can be interrupted immediately. Logout does not affect the status of any business layer messages. All valid
Business layer messages can be executed after logout.
4.3 Recovery
4.3.1 Overview of Session Recovery Mechanism
The session layer recovery mechanism of this standard is compatible with the FIXT session protocol and cannot be used as a true message recovery mechanism.
The terminal should obtain the missing data through the message recovery mechanism of the application layer.
LFIXT participants only have message sequence number synchronization during the session establishment phase, and do not provide real message recovery during the session duration, but
Send a message retransmission request simply by responding to the message.
4.3.2 Login message processing
When the LFIXT participant is the receiver of the session, only the NxtIn of the party needs to be set as the initiator's Logon message to the initiator's Logon
In the message. The recipient of the conversation does not need to check any gaps and will
The receiver will not request any message retransmission from the initiator. If the session initiator does not provide a field,
Then the NxtOut of the session receiver is set to 1.
4.3.3 Retransmission request message processing
LFIXT participants will not actively send retransmission requests, but may receive retransmission requests from FIXT participants. When LFIXT participants receive
When retransmitting the request, the message will be used to reset the sender's serial number, instead of providing historical message retransmission.
4.3.4 Sequence number reset message processing
When the LFIXT participant receives the sequence number reset message, it will reset its own party according to the sequence number reset message.
5 Message specification
5.1 Message structure
5.1.1 Components of the message
Each message consists of a message header, message body, and message tail. The message always starts with a standard message header and ends with a standard message tail.
5.1.2 Message header
All messages exchanged by the two parties in the conversation have a standard message header, and the fields contained in the message header are shown in Table 1.
Every message starts with a standard message header. The message header specifies the type, length, destination, sequenc...
Tips & Frequently Asked Questions:Question 1: How long will the true-PDF of JR/T 0182-2020_English be delivered?Answer: Upon your order, we will start to translate JR/T 0182-2020_English as soon as possible, and keep you informed of the progress. The lead time is typically 3 ~ 5 working days. The lengthier the document the longer the lead time. Question 2: Can I share the purchased PDF of JR/T 0182-2020_English with my colleagues?Answer: Yes. The purchased PDF of JR/T 0182-2020_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet. Question 3: Does the price include tax/VAT?Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countriesQuestion 4: Do you accept my currency other than USD?Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay.
|