iLink 3 uses the FIX Performance (FIXP) protocol to establish and manage bi-directional sessions. Per the FIXP protocol, a FIX session is defined as a bi-directional stream of ordered messages between two parties within a continuous sequence number series. With iLink 3, the Market Segment Gateways (MSGW) will support weekly client FIX sessions and also support mid-week initialization.
...
Each FIXP session established at the start of the week, intra-day, or at the beginning of each trading day is represented is represented with a unique UUID value set by the customer as a 64-bit value. CME Group recommends using the system timestamp, which represents the number of microseconds since epoch (Jan 1, 1970) as the timestamp. Business messages received from the exchange are recoverable for that sequence number + UUID combination.
...
| Info |
|---|
Only the field value—not the field name—must be used for the calculation of HMAC signature. Example: where SessionID=<ABC>, use only 'ABC'. |
Step 1 - Create the Canonical Message
...
The required FIXP fields in the Establish message are:
RequestTimestamp RequestTimestamp (A timestamp older than 5 seconds will be rejected as stale.)
- UUID
- SessionID
- FirmID
- TradingSystemName
- TradingSystemVersion
- TradingSystemVendor
- NextSeqNo
- KeepAliveInterval
An Example Canonical message for Establish:
“RequestTimestamp” + "\n" + “UUID” + "\n" + “SessionID+ "\n" + FirmID+ "\n" + “TradingSystemName” + "\n" + “TradingSystemVersion” + "\n" + “TradingSystemvendor” + "\n" + “NextSeqNo” + "\n" + “KeepAliveInterval”
...
Step 2 - Create Signature Using the Secret Key and Canonical FIX Message
The signature is a hash (digest) of the canonical message created in Step 1 using the Secret Key provided by CME.
The Secret Key downloaded from Request Center is Base64 URL Encoded. Customers must decode the secret key first.
Example of Creating Signature Using HMAC SHA256 in Java 8+
The HMAC signature is populated in a fixed length string field (i.e. String32Req) since SHA-256 signature is always 32 bytes.
...
- If a fill is generated for the GTC or GTD order in the current trading day before Initialization then the exchange processes the Execution Report and increments its previous sequence number for the previous UUID, which is the last known UUID from the previous session.
- When the customer sends Negotiate and Establish messages to Initialize then they will receive an Establishment Acknowledgment message with:
- PreviousSeqNo as “last known value+1”. This is higher than the client’s last known expected inbound sequence number, which is "last known value" for the PreviousUUID.
- PreviousUUID="last known value".
- As a result, the client application sends a Retransmit Request for the PreviousUUID and PreviousSeqNo and receives the undelivered Execution Reports on the GTC order.
The sequence gap is now filled and normal processing continues.
...
- The customer must Establish the FIXP session without session without Negotiation (Binding without Initialization).
- It is recommended that the same UUID be used, else the sequence stream will not be contiguous with the previous FIXP session.
- If a different UUID is used, the customer must reset their inbound and outbound sequence numbers to “1”.
- If the same UUID is used, the customer must use the next sequential inbound and outbound sequence numbers.
...
Setting inbound and outbound sequence numbers back to "1" is possible only with the use of a new UUID, which requires Negotiation and Establishment.
...
- Reset the inbound and outbound sequence numbers to “1” prior to Negotiating at the start of each week and subsequently at the start of a FIXP session with a new UUID.
- Increment inbound sequence number by one for each message received from the exchange for a particular UUID.
- Increment outbound sequence number by one for each message sent to the exchange for a particular UUID.
- Issue a RetransmitRequest when a sequence gap is detected from the exchange for a particular UUID.
- Retransmit responses will be interleaved with other real-time original message transmissions if any.
- If the exchange detects a sequence gap from customer, then a Not Applied message will be sent and the customer can take action as needed.
- This can include sending a Sequence message instructing the exchange to ignore the gap and proceed ahead with the NextSeqNo (recommended behavior).
- This can include trying to replay the messages missed by the exchange (although this is not recommended behavior).
- Maintain sequence numbers between multiple FIXP sessions (a FIXP session occurs each time a customer Establishes session with CME iLink 3) on the basis of assigning a unique UUID for each connection.
- If customer chooses to use fault tolerance then maintain sequence numbers for a particular UUID among the primary and backup processes during fail-over scenario.
- The Sequence, Establish, Establishment Acknowledgment and Retransmission messages are sequence forming since they contain the NextSeqNo, which indicates the sequence number of subsequent business messages.
- FIXP messages themselves are not assigned a sequence number; they only carry a reference as to the next expected sequence number of the next business message to be sent.
- All business messages will explicitly be assigned a sequence number.
- Since there is no heart beat message, the Sequence message itself serves as the de-facto heart beat and at a minimum it must be sent after the lapse of each KeepAliveInterval if no other messages are being sent.
- Since there is no test request message, the Sequence message also acts as a pinging message with KeepAliveIntervalLapsed=1 to inform the other side that no message has been received from it.
CME Globex preserves all outbound sequence numbers for recovering missed business messages sent from the exchange to the customer during a failover scenario. Business messages sent from the customer to the exchange are not recoverable by the exchange.
...
After sending a Terminate request, the client application should wait for a Terminate confirmation message before closing the socket connection. When a customer's FIXP session is terminated gracefully then the status of pending orders remains unaffected (for one way termination due to an error working orders may be cancelled through Cancel-on-Disconnect functionality). All active orders will continue to be eligible for execution after Termination. Any unsent Execution Report responses are sent via customer-initiated Retransmit Request after they have Established a FIXP session. If the FIXP session is Re-Negotiated intra-day with a different UUID then the unsent Execution Reports will be recoverable only by referencing the previous UUID and previous sequence number.
...
The client application must Negotiate and Establish with the designated primary Market Segment Gateway and then Establish with the backup Market Segment Gateway. A backup member must be ready to activate in the same data state as the former primary member being replaced. For example, inbound and outbound sequence numbers for a UUID must be maintained in a consistent state during fail-over between both processes.
Note: for active-active fault tolerance, Negotiation is is not allowed allowed on the backup connection.
The customer must must use the same UUID for both primary and backup FIXP sessions (this is the only exception to the general rule of thumb that the UUID be globally unique) and then the sequence streams would be contiguous after failure.
...
The customer must avoid populating NextSeqNo with a non-zero number in Establish and Sequence messages to the backup Market Segment Gateway, as this will be considered a protocol violation. The NextSeqNo in these messages must be set to zero. Likewise the reverse situation is also true, i.e., setting NextSeqNo as zero in Establish in Establish and Sequence messages Sequence messages to the primary Market Segment Gateway will be considered a protocol violation.
Business messages (e.g. New Order - Single, Order Cancel/Replace Request) must be sent only through the primary content stream where sequencing is enforced per FIXP protocol. Communication over the backup content stream is solely for link maintenance; only administrative messages (Negotiate, Establish, Sequence, Terminate) are sent through the backup content stream.
...
- If the primary client process fails without closing the TCP connection, then it takes two times the KeepAliveInterval for the exchange to detect the primary process failure. If the customer would like to avoid the time delay in this process, then they should ensure the TCP connection is closed whenever their application fails.
- Before the fail-over, the backup client application was receiving NextSeqNo set to zero. During and after the fail-over process, the backup client application is responsible for ensuring that its UUID, inbound sequence number to the exchange and outbound sequence number from the exchange are synchronized with the primary application that just failed. This is critical since the newly elected primary member must know exactly where the failed member left off.
- If the NextSeqNo number of the Sequence message sent by the new primary client application is lower than that of the original client application for the same UUID, the exchange will terminate the client application as per FIXP protocol.
- If the NextSeqNo number of the Sequence message sent by the new primary client application is lower than that of the original client application for a different UUID, the exchange will accept that and will also inform the customer of the perceived gap by sending a NotApplied message; if the NextSeqNo=1 in this case for a new UUID then that is acceptable.
...