This topic describes an overview of the session Negotiation and Establishment process.

Contents

The customer uses the Negotiate and Establish messages to authenticate themselves with the Market Segment Gateway. In iLink, there are three different types of Initialization and Binding operations.

Beginning of Week Initialization and Binding

Beginning of Week initialization and Binding will involve the very first messages (Negotiate and Establish) that the customer sends for the week. The customer must reset their inbound and outbound sequence numbers to “1” prior to initialization at the start of the week as well as pick a globally unique UUID for each FIXP session.

If the client system to CME Globex outbound sequence number is not reset to “1” at the beginning of the week prior to Start of Week Initialization, and the client sends a Establish message (Negotiate does not have NextSeqNo), the Market Segment Gateway responds with a Terminate message. The Terminate message will have a Code indicating a failure to reset sequence numbers at the start of the week. The customer must then reset sequence numbers and reattempt the Initialization.

GTC and GTD Orders - Beginning of Week

Good Till Cancel (GTC) or Good Till Date (GTD) orders sent by a customer from the previous week continue to be eligible for execution after Termination (done for day).

• If a fill is generated for the GTC or GTD order in the current week before Start of Week Initialization, then the exchange processes the Execution Report and increments its previous sequence number for the previous UUID (which is the default UUID of 0) accordingly.

• When the customer sends Negotiate and Establish messages to Initialize at the Start of the Week for the current week, they will receive an Establishment Acknowledgment message with:

  • PreviousSeqNo = “1”.

  • PreviousUUID="0". This way the client knows that a message was published using the default CME assigned UUID of 0 since iLink requires the exchange also to reset its sequence numbers to “1” and UUID to "0" prior to Start of Week Initialization.

• As a result, the client application sends a Retransmit Request for the PreviousUUID and PreviousSeqNo and receives the undelivered Execution Report on the GTC order.

• The sequence gap is now filled and normal processing continues.

Mid-Week Initialization and Binding

Mid-Week Initialization and Binding will involve Negotiating and Establishing a new FIXP session once the previous one has ended gracefully following Termination. The customer must populate NextSeqNo with the correct value from the previous sequence stream associated with the previous UUID and reattempt the Initialization, or reset sequence number to 1 with the new UUID.

If the customer's inbound sequence number is reset to “1” when Initializing a new FIXP session with the same UUID as the previous one and the customer sends an Establish message (Negotiate does not have NextSeqNo), then the Market Segment Gateway responds with a Terminate message. The Terminate message will have a code indicating an error condition regarding usage of lower than expected sequence numbers. The customer must populate NextSeqNo with the correct value from the previous sequence stream associated with the previous UUID, or populate NextSeqNo with the correct value from the previous sequence stream associated with the previous UUID and reattempt the Initialization.

GTC and GTD Orders - Mid-Week

Good Till Cancel (GTC) or Good Till Date (GTD) orders sent by a customer from the previous trading day continue to be eligible for execution after Termination.

• 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.

Intra-Session Binding

Intra-session binding is applicable when the FIXP session loses connectivity with the exchange for any reason such as Termination due to a protocol violation, failure, etc. In such an event:

• The customer must Establish the FIXP 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.

Intra-Session Binding is used for any subsequent binding after a successful Beginning of Week or Mid-Week initialization and Binding.

Intra-Session Binding uses the sequence number series that continues from the next sequence number where the customer was Terminated for the same UUID. As a result, customer must populate NextSeqNo with the correct value from the previous sequence stream associated with the previous session. In the case of no business messages from the previous session, the Intra-Session Establish message can have a NextSeqNo set to “1" for that same UUID.

Setting inbound and outbound sequence numbers back to "1" is possible only with the use of a new UUID, which requires Negotiation and Establishment.

If any of the above requirements are not met, the client application receives a Terminate message. In addition, iLink does not increment its inbound sequence number.

Intra-Session Establish provides handling for undelivered messages while the client application has not established a FIXP session.

• While the customer is not established, Execution Reports, etc. are processed by the exchange.

• As a result, the customer may receive an Establishment Acknowledgment message with PreviousSeqNo higher than expected (i.e., the Market Segment Gateway processed those Execution Reports and incremented its outbound sequence number accordingly) for the previously used UUID.

• The client application submits a Retransmit Request message for those messages persisted while the customer was not established.

Session Negotiation

A FIXP session connection is initiated by the customer using a Negotiation message. The UUID must be sent in the Negotiation message and that ID is used for the lifetime of the FIXP session. Negotiation is provided as a mechanism used for the customer to declare what ID they will be using. There is no concept of resetting a FIXP session. Instead of starting over a FIXP session, a new FIXP session is negotiated with a new UUID.

The Negotiate message also identifies the types of message flow in each direction of a FIXP session using the FlowType field. The types of message flow supported by iLink are Idempotent from customer to exchange and Recoverable from exchange to customer.

• FlowType=Recoverable has the highest delivery guarantee and guarantees exactly-once message delivery. If gaps are detected by the customer, then missed messages may be recovered by retransmission.

• FlowType=Idempotent guarantees at-most-once delivery. If gaps are detected by the exchange, then the customer is notified, but no attempt is made by the exchange to recover missed messages. Any course of action in this scenario is incumbent upon the customer.

The Negotiate message should be used in these circumstances:

• Beginning of the week (start sequence numbers from 1)

The Negotiate message can be used in these circumstances as well: 

• Midweek with new UUID after Termination of previous session by customer

• Midweek with new UUID after ungraceful termination (with error code) and to restart sequence numbers from 1

• Midweek with new UUID after graceful termination (without error code) and to restart sequence numbers from 1

The following required string fields cannot contain empty bytes:

• HMACSignature

• AccessKeyID

• Session

• Firm

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

• UUID 

• RequestTimestamp

The customer should send a Negotiate message to the exchange and await acknowledgment.

• When Negotiate message from customer is accepted by CME then CME will return a Negotiation Response.

• When Negotiate message from customer is rejected by CME then CME will return a Negotiation Reject.

• If no response is forthcoming from the exchange after two times the recommended KeepAliveInterval has lapsed then Negotiation can be retried or out-of-band inquiry may be made to determine application readiness.

Negotiate Message Accepted

This diagram shows an example of Negotiation Accepted.

Negotiation Rejected

This diagram shows an example of negotiation Rejected.

Session Establishment

After negotiation is complete, the customer must send an Establish message to start assigning sequence numbers. Once established, the customer can proceed to submit orders and quotes. The established state is concurrent with the lifetime of a TCP connection. A customer may re-establish a previous FIXP session after reconnecting without any further negotiation (Intra-Session Initialization). Thus, Establish binds the FIXP session to the new transport instance.

Both the customer and the exchange should signal each other that a disconnection is about to occur using a Terminate message. This unbinds the transport from the FIXP session, but it does not end a logical session hence there is no need to Negotiate again intra-day for the same trading day.

• If connection is disconnected then the customer may re-establish the same session (same UUID) after reconnecting without any further negotiation, which ensures that the sequence numbers will continue.

  • Messages published after disconnection (cancel on disconnect) may be recovered in the next session.

• If connection is terminated then the customer must negotiate and establish a new session with a new UUID after reconnecting and this resets the sequence numbers back to 1 both ways (customer to CME and CME to customer).

  • Messages published after Termination (mass quote cancels) may be recovered in the next session through previous UUID.

• If connection is terminated then the customer may also re-establish the same session (same UUID) after reconnecting without any further negotiation, which ensures that the sequence numbers will continue.

  • Messages published after termination (mass quote cancels) may be recovered through the same UUID.

Once the Establish message is sent by the customer to CME, they must wait for an acknowledgment before initiating any other action.

• If no response is received after KeepAliveInterval, then send the Establish message again. After the second attempt, manual escalation may be required.

A FIXP session that has a recoverable flow may be re-established by sending Establish with the same session UUID and exchange of business messages may continue until all business transactions are finished.

An Establish message attempts to bind the specified logical FIXP session to the transport that the message is passed over. The response to Establish is either Establishment Acknowledgmen tor Establishment Reject. The exchange will evaluate NextSeqNo in the Establish message to determine whether it missed any messages after re-establishment. If so, it will immediately send a NotApplied message after sending EstablishmentAck. 

Establish message should be used in these circumstances:

• Beginning of the week after Negotiate and starting sequence numbers from 1 with same UUID as Negotiate.UUID

• Midweek after disconnection and continuing sequence numbers from the same session such that UUID=previous Establish.UUID

• Midweek after termination from CME and continuing sequence numbers from the same session such that UUID=previous Establish.UUID

• Midweek after termination from customer and continuing sequence numbers from the same session such that UUID=previous Establish.UUID

• Midweek after termination from customer and negotiation (with new UUID) and restart sequence numbers from 1 such that UUID=Negotiate.UUID 

• Midweek after termination from CME and negotiation (with new UUID) and restart sequence numbers from 1 such that UUID=Negotiate.UUID

• Midweek after termination from customer and negotiation (with new UUID) and restart sequence numbers from 1 such that UUID=Negotiate.UUID

If the Establish message is not sent within a timeout interval of 60 seconds after the Negotiation Response then the session will be Terminated with code=1

The following required string fields cannot contain empty bytes:

• HMACSignature

• AccessKeyID

• Session

• Firm

• ApplicationSystemName

• TradingSystemVersion

• ApplicationSystemVendor

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

• UUID

• RequestTimestamp

• KeepAliveInterval

• NextSeqNo

Establishment Accepted

This diagram shows an example of Establishment Accepted.

• When the Establish message from the customer is accepted by CME, then CME will return an Establishment Acknowledgment.

  • MessageSequenceNumber will be populated by CME accordingly:

    • Beginning of the Week → MsgSeqNo=1

    • Midweek → MsgSeqNo=LastMsgSeqNo+1 if UUID=Last Establish.UUID and Establish without Negotiate

    • Midweek → MsgSeqNo=1 if Establish used after Negotiate

  • CME Globex will notify the customer if any messages were published by CME while they were not connected with either default UUID assigned by CME or last known customer assigned UUID.

Since the communication flow from the exchange is recoverable, it will fill the NextSeqNo, PreviousUUID, and PreviousSeqNo fields appropriately, allowing the customer to start requesting the replay of messages that they have not received.  

• The customer should evaluate NextSeqNo, PreviousSeqNo and PreviousUUID to determine whether they have missed any messages after re-establishment of a recoverable flow. If so, the customer can then immediately send a Retransmit Request.

Establishment Rejected

This diagram shows an example of Establishment Rejected.

When the Establish message from the customer is rejected by CME, CME will return an Establishment Reject.