Contents

Termination

Terminate message is used to signal that the sender is going to disconnect the TCP socket connection. This unbinds the transport from the session, but it does not end a logical session. The Terminate message initiates and confirms the termination of a FIXP session.

• Terminate message can be sent by Customer to conclude the session.

• Terminate message can be sent by CME upon FIXP protocol violation or other error condition such as volume controls and auto port closure.

• Terminate message should be sent by receiver in response to Terminate message sent by requester (to conclude session) and then receiver can proceed to disconnect TCP socket connection.

  • Requester should take down the socket only after receiving Terminate response; if no response is received after one KeepAliveInterval has passed, then proceed to disconnect assuming the socket connection has gone stale.

• Terminate message sent by sender for an error condition does not require corresponding response from the receiver.

  • Sender can proceed to disconnect the socket connection without waiting for receiver to first take down the socket.

When the client system sends a Terminate message, the Market Segment Gateway sends a corresponding Terminate confirmation message and terminates the FIXP session. After sending a Terminate message, the customer should not send any additional messages, since this will be considered to be a protocol violation.

Terminate - Client Initiated

This diagram shows an example of client-initiated Terminate.

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.

For the customer who chooses to use fault tolerance, the following must be noted: if the primary client application is terminated, then the backup application will also be terminated.

Graceful Termination from the exchange will take place at the end of the week when the exchange tells the customer that it is done for the day at the conclusion of the trading week and has no more messages to send.

Ungraceful Termination takes place for the following reasons:

• One of the peers receives a Terminate message due to protocol violation, a specific example of protocol violation is to send Establish with a new UUID without Negotiating.

• Hard disconnect of the TCP socket connection.

• Two times the KeepAliveInterval has expired and no Sequence message is received.

The Market Segment Gateway disregards any message that cannot be decoded or fails a data integrity check and does not increment the inbound implied sequence number. Processing the next business message will cause detection of a sequence gap and a NotApplied message will be generated. If the previously disregarded message is valid when resent, normal processing will continue; if the previously disregarded message remains in error, then NotApplied messages will loop until the next Sequence message following the bad message. The customer must detect this condition and perform the corrective processing to avoid it.

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

• UUID

• RequestTimestamp

• Code

Terminate - CME Initiated

This diagram shows an example of CME-initiated Terminate.