Contents

Sequence 

Not all FIXP messages are assigned a sequence number, but instead communicate the sequence number of the next business message or the last business message.

• All business messages will be assigned sequence numbers and FIXP messages refer to these sequence numbers.

• This is unlike the official FIXP specification in which business messages have implicit sequence numbers.

• Sequence message is used in both Recoverable (CME to customer) and Idempotent (customer to CME) flows.

• Sequence numbering supports ordered delivery and recovery of messages.

The Sequence message serves four purposes in an iLink FIXP session including:

• de facto heartbeat message

• test request ping message

• failover trigger message (from primary to backup)

• sequence reset to let the exchange know what sequence number to expect next from the client system

This will let the exchange sync up the NextSeqNo with its own inbound sequence counter and identify a gap if any. Likewise the customer can infer what sequence number to expect next from the exchange and can sync up the value of NextSeqNo with their own inbound sequence counter and identify a gap if any.

The Sequence message can also be sent in response to a NotApplied message as a gap fill if it contains a higher than expected NextSeqNo value and not lower than expected.

The Sequence message is also sent at regular intervals similar to the heartbeat message to ensure that the connection between the customer and exchange is in a normal state. The KeepAliveInterval is specified while Binding in the Establish message. If there is other messaging activity in progress then the Sequence message need not be sent unless a KeepAliveInterval lapses, in which case it will function as a test request ping message.

• It is recommended to set the KeepAliveInterval at 5-60 seconds.

• The exchange will send the Sequence message interleaved with Retransmission responses to a Retransmit Request as well.

In the absence of other messaging activity, if a Sequence message is not received after 2 times the KeepAliveInterval has lapsed, then this is considered a protocol violation and will lead to the FIXP session being terminated.

A sequence message is used in these circumstances:

• From customer - to reset sequence number in response to Not Applied message sent by CME when CME detects a sequence gap from customer.

• From CME - as a heartbeat message to be sent when a KeepAliveInterval interval from CME lapses and no other message is sent to customer.

• From customer - as a heartbeat message to be sent when a KeepAliveInterval interval from customer lapses and no other message is sent to CME.

• From CME - when a KeepAliveInterval of the customer lapses without having received any message from them then send message with KeepAliveIntervalLapsed=1 as a warning before initiating disconnect of socket connection.

• From customer - when a KeepAliveInterval of CME lapses without having received any message from CME then send message with KeepAliveIntervalLapsed=1 as a warning before initiating disconnect of socket connection.

The following integer fields will be checked for these boundary conditions:

• UUID

• NextSeqNo

• KeepAliveIntervalLapsed

• FTI

Heartbeat

This diagram shows an example of Sequence used as a heartbeat.

Warning

This diagram shows an example of Sequence used as a Warning due to KeepAliveInterval lapsing prior to Terminate.

Retransmit Request

The Retransmit Request message is sent to request a retransmission of missed messages when the customer detects a gap in the incoming sequence number series from the exchange. In iLink, the Retransmit Request is used to request all messages subsequent to a particular message by using the following fields:

• UUID: the UUID associated with the sequence numbers being requested.

• FromSeqNo: message sequence number of first message in range to be resent.

• Count: count of messages being requested (if defined as zero then this means infinity or latest sequence number).

The exchange itself will not send a Retransmit Request to recover missing messages, instead a Not Applied message is sent to indicate that the exchange has seen a gap in sequence numbers from the customer and it is the customer who can choose how best to respond to this:

• Send a Sequence message with the appropriate value in NextSeqNo where the customer wants to start sending messages from.

• Retransmitting the missed messages.

• Ignoring the NotApplied message and keep trying to moving ahead.

  • This not advisable since the exchange will keep sending a Not Applied message for the same sequence gap.

• Terminating the FIXP session and Re-Establishing with a new UUID.

  • This is not advisable and should be used only in extreme failure cases to recover from lower than expected sequence number error condition since the sequence streams get reset back to '1' both ways between customer and exchange.

Since the customer is receiving a recoverable flow from CME, they can use Retransmit Request to recover missed messages. When the customer sends a Retransmit Request message, the exchange resends all reject messages and/or execution responses using the same message sequence numbers as the original transmissions along with Sequence messages if any. FIXP messages are not replayed, only business messages.

• The Gateway resends messages for the current UUID or all previously used UUIDs for that week only. Messages from previous weeks are not resent.

• If the customer sends a Retransmit Request message to the Gateway—even if the Gateway has already sent a Not Applied message—then that request will be fulfilled by the exchange.

• The customer should accept messages with a higher sequence number from Market Segment Gateway after recognizing a gap. However, their application should queue messages for in-sequence processing after a requested retransmission is received and completed from the Gateway.

• Retransmission implies that subsequent messages are sequenced with a lower sequence number in response to a Retransmit Request.

• Retransmission responses from the exchange to customer may be inter-leaved with other real-time messages based on the PossRetransFlag (Tag 9765) such that replayed messages will be 9765=1 and original messages will be 9765=0.

• It is the customer's responsibility to determine whether the current batch fills the original gap. If not, then they should send another Retransmit Request for the remainder. Requests and responses should proceed iteratively until all desired messages have been retransmitted. This can be done by combining NextSeqNo+Count from all Retransmission messages.

• If the exchange is unable to retransmit requested messages, it responds with a Retransmit Reject message.

• If a customer Retransmit Request exceeds the maximum resend limit (2,500 messages) then the exchange sends a Retransmit Reject message. The customer should initiate separate Retransmit Requests for each batch of 2500 messages.

• Only one Retransmit Request is allowed in-flight at a time per FIXP session. Another Retransmit Request must not be sent until the previous request has concluded otherwise it will be rejected.

The following integer fields will be checked for these boundary conditions:

• UUID

• LastUUID

• RequestTimestamp

• FromSeqNo

• MsgCount

Retransmission

Retransmission message is sent in response to a valid Retransmit Request from customer.

When RetransmitRequest message from customer is accepted by CME, then CME will return a Retransmission followed by replaying business messages.

• If no messages are replayed, the Retransmission message will be followed by a Sequence message confirming the next sequence number to be sent for the current UUID.

While messages are being replayed, they may be interleaved with other real-time messages; tag 9756-PossRetransFlag on business messages provides the means to distinguish replayed messages from real-time messages:

• tag 9765=1; replayed messages

• tag 9765=0; original messages