TCP Replay Overview

TCP replay should be used for small-scale data recovery (refer to “Implementation Considerations” on Page 84 for additional information). Client systems can recover specific messages that were missed using the sequence number and the TCP historical replay component. This method recovers all missed messages. CQG logs IP addresses, ports, and passwords of the originator and the Channel ID and range of the requested sequence number.

The TCP historical replay component allows you to request a replay of a set of messages already published on the UDP Incremental Market Data Channel. The request specifies messages to be replayed. The request is submitted with the FIX Market Data Request message (35=V). In response, CQG sends the requested messages and a Logout (35=5) message. A Logout (35=5) message is also sent in case of rejection of the initial request, tag 58-Text will list the reason for the logout.

This type of request is sent through a new TCP connection established by the customer. When making the request, the channel and sequence number are specified. The responses are sent by CQG through this same connection and the connection is then closed by CQG once the replay is complete. All requests from the client system to CQG are in FIX format. All responses from CQG to the client system are FIX encoded (including the reject response). The TCP Replay contains a stop-bit delimited block size represented as an unsigned integer in FAST. This stop-bit is used instead of FIX’s current 2 byte separator. Replay is limited in the number of messages that can be requested.

Note: Client systems should queue real-time data until all missed data is recovered. The recovered data should then be applied prior to applying the queued data.

Implementation Considerations

The following are limitations to consider prior to implementing TCP replay functionality:

      TCP requests and responses are via TCP.

      Resend request messages and other inbound messages (i.e. heartbeat) are in FIX format, outbound response messages are FAST encoded.

      There is a 24 hour time limit on the number of messages available via the TCP replay functionality.

      The maximum number of messages that can be requested in one resend request message is 2000.

Note: Only one Market Data Request can be processed during the current established session. If multiple Market Data Requests are sent when the session is established, only the first Market Data Request is processed and subsequent Market Data Requests are ignored. You must re-establish a new session with the TCP Replay server when the current Market Data request is processed ( Login then Logout) and send a new Market Data Request ( tag 35-MsgType = V) message.

Process

1.  Customer establishes a TCP connection.

Refer to the configuration file for TCP IP and port information. For additional information on the configuration file, refer to Template Dissemination.

2.  Customer sends Logon (tag 35-MsgType=A) message to CQG.

Customer Username and Password are verified. If the Username and Password are incorrect, a Logout (tag 35-MsgType=5) will be sent.

3.  CQG sends Logon (tag 35-MsgType=A) message to the customer.

CQG will send a Logout (tag35-MsgType=5) message if a Market Data Request (tag35-MsgType=V) is not received in 5 seconds.

4.  Customer sends Market Data Request (tag 35-MsgType=V) message to CQG.

Client systems must indicate the channel ID (tag 1180-ApplFeedID) and sequence numbers (tag 1182-ApplBeginSeqNo and tag 1183-ApplEndSeqNo) in the Market Data Request (tag 35-MsgType=V) message.

5.  CQG sends Heartbeat (tag35-MsgType=0) messages to customer every 2 seconds until the first recovery message is sent.

The heartbeat feature is not implemented yet.

6.  CQG sends FIX recovery messages that were requested by the customer in the Market Data Request (tag35-MsgType=V) message.

7.  CQG sends a Logout (tag35-MsgType=5) message to the customer.

CQG will close the TCP connection if the customer does not send a Logout (tag 35-MsgType=5) message within 5 seconds from the time CQG sends a Logout (tag35-MsgType=5) message.

8.  Customer sends a Logout (tag 35-MsgType=5) message to CQG.

9.  CQG closes the TCP connection.