Fix Protocol Communication Process

The biggest advantage of the network is that it saves time. Especially in business activities, it has outstanding advantages. With the continuous evolution of networks, we require more networks and the complexity of building network protocols. Now let's introduce the Fix protocol. The Fix protocol can be divided into two parts: Session-layer protocol and business-layer protocol.

The Session Layer defines data communication protocols, and the business layer defines the business data structures related to financial activities. The Fix Session Layer fully considers stability, security, robustness, and efficiency. Stability means that heartbeat messages are defined in the Session Protocol to maintain Session connections. Security means that the protocol supports data encryption from the message structure. Error retransmission means that each session maintains a set of message serial numbers at each of the two endpoints, prevent message loss and missed messages. In this case, you only need to check the continuity of the serial numbers on both sides to determine which messages need to be re-transmitted.

The communication parties of the session maintain an incomming and an outgoing serial number. The Incomming serial number is used to check whether the serial number is out of order or spans. The heartbeat is set in the heartbeat domain when the initiator sends a logon message. The heartbeat interval between the acceptor and the initiator is the same.

Fix messages must be processed in ascending order of serial numbers. If packet loss occurs during sending and receiving, there are two policies: re-transmission of packets with serial numbers errors and all packets received in the future; the other is to re-transmit packets with errors only. The Fix protocol does not define a response message, and uses the serial number to detect message loss. The checksum, signature, or message body length is used to detect message errors; in the Logon stage, the client selects an encryption key, but the server selects different keys in the returned logon Message. At this time, the client also needs to send a logon message to the server, which has two functions:

1) Let the server know that the key change has received the client's response;

2). The following message is encrypted.

After the logon stage is complete, you must check the serial number immediately to send and receive messages synchronously. For example, if one end sends a message but the other end does not receive the message, re-transmission is required. You can detect missed messages by comparing the serial numbers in a logon message with the expected serial numbers of messages received by the Communications party.

It is best to reset the serial number once every 24 hours. Before resetting, we should discuss which party should first send the reset request and the time of sending the reset request. Before resetting, one party must first send the testrequest message, wait for the heartbeat message to confirm whether the connection is normal, then send the logon message, and set the serial number in the message to Y, when the serial number is set to 1, the receiver replies to the same message and the message is successfully reset. Before Logout, The testrequest message needs to be sent to force the heartbeat to check whether the message serial number is continuous. After the logout message is sent, wait for a period of time to receive the logout Response Message. During this period, both parties will handle the inconsistency of the serial number. Once the serial number is synchronized, the logout receiver will immediately send a response to the Logout message, the Logout initiator is responsible for closing the session after receiving the response.

In Fix4.4, The NextExceptedSeqNumb domain is added to the logon message to indicate the next serial number that the Party expects the other party to send. In this way, after the logon stage is complete, it directly resends the missed message and does not need to send testrequest again, heartbeat and ResendRequest messages.

The difference between possResend and possDupFlag is that the former uses the new serial number to send the old message. You can check the message domain to determine whether the modified message has been received, such as the order ID; the latter resends a message with an old serial number. You can directly check the serial number to determine whether the message has been received. If the message has been received, the message is discarded. The logon message contains two fields: RAW Data Length and RAW data, which are used to store the Data required for authentication. The FIX protocol has standardized some business processes in specific implementation, considering the differences in business models and application environments around the world, the FIX Committee also leaves the implementers with considerable room for maneuver. In this space, the implementers can define special application requirements. In the FIX protocol, there are two layers of session layer and application layer), the main task of the Session Layer is to establish and maintain the connection between the two sides of the information exchange, and the security, integrity and consistency in the information exchange process. In specific implementation, since the session layer has clearly described how to implement it, it is relatively easy to implement it.

The Application Layer defines specific business interfaces and also includes the business logic in these business interfaces. Therefore, I have many opinions on the application layer industry. First, the FIX Protocol application layer is a standard interface, which can be used to define brokerage and brokerage, brokerage and exchange among institutions) or internal application business interfaces. Second, it is not just an interface. There is a clear business logic between these application layer information. We can think that the FIX protocol is an application interface with a session layer. Therefore, the implementation of the FIX protocol is not only the unified specification of interfaces, but also the process of extending the business logic to information exchange. Generally, the business logic of the FIX protocol is implemented through the FIX Engine. The major function of the FIX engine is to generate the corresponding business request information according to the business needs), and finally deliver the exchange information to the target FIX engine in a point-to-point manner through a third party; at the same time, the FIX engine parses the received information and generates corresponding response information. The information parsing process is actually the implementation process of the business logic.

Its task is to extract the domain information required by the application-layer interface of the FIX protocol from the Information Library, compress the information in the format required by the FIX Protocol into a data packet, and then submit the data packet. First, the FIX engine features the above features at the application layer. Second, the FIX engine is an interactive process in the Process of processing information, in addition to the original request and broadcast information, the response information of the FIX protocol generates data packets according to the business logic between the information. During the packet generation process, other related information is exchanged, for example, an Order information Order-Single) is generated during information interaction, such as securities information, quotations information, and quotation information IOI, the FIX engine will follow the domain, information type definition, data dictionary conventions of the FIX protocol, and the corresponding information freezing. Finally, the FIX engine also makes an agreement on the custom domains and types of information exchange between the two parties. These agreements will be fully applied throughout the information exchange process.