Main Usage
The use cases provided here should be considered as basic pointers. To find more technical and in-depth information refer to the “Quotes Direct - Core Functionality” document.
Logon / Definitions Requesting & Receiving
1. The FIX client sends a logon request to SDS using standard FIX logon message (tag 35=A).
2. If SDS accepts the Logon attempt, it responds with FAST encoded FIX logon message (tag 35=A).
3. The FIX client requests the security definitions for a given feed ID using standard FIX SecurityDefinitionRequest message (35=c).
4. The server sends the Security Definition messages for which the account has enablements. The response is FAST-encoded.
5. Each security definition contains information about the feed configurations (IP, Port) for the corresponding incremental, snapshot, and replay connections.
6. The connection with SDS can be maintained to facilitate the transfer of new Security Definitions as they are added. However, SDS may drop an idle connection at any time.
FIX clients should expect new SecurityIDs at Sunday 9:00 a.m. US central time (i.e. on the start of every service week).
Receiving Real-time Incremental Updates
1. The FIX client joins an incremental multicast group.
2. Each multicast group provides updates for contracts from only one FeedID. SDS sends the data feed connection details in every security definition message.
3. Quotes Direct system broadcasts all available contract updates. Each update has a SecurityID reference field.
4. If the SecurityID matches a Security Definition received from SDS, the client system processes the message.
5. Messages with SecurityIDs not explicitly received from SDS should be dropped.
Receiving Snapshot Updates
1. The FIX client joins a special multicast group to receive the current market state.
2. The FIX Sender disseminates the snapshots, each of which has its own sequence number and the total number of reports in current cycle.
3. The FIX client listens to the snapshots until all of them arrive (confirmed when the total number of reports received during current cycle match the total number of expected reports) and closes the socket.
4. Then it processes the snapshots using the security IDs received from SDS.
Error Handling
Data Gaps Processing (Client-Side)
Whenever discrepancies in the data feeds are detected, the client system could request the lost/corrupt data from the Replay Server.
1. The client system logs on to the TCP Replay Server and requests a replay of the missed messages specifying the FeedID and the range of sequence numbers to replay.
2. Only 2000 messages can be requested from the Replay Server per session.
3. The Replay Server responds with the requested data and terminates the connection.
Failover Use Cases
1. When the Primary FIX feed may switch to the backup FIX feed, a 'Sequence Number Reset' message is sent and all sequence numbers restart from '1'. When this occurs, the FIX client should open the snapshot channel to refresh the instruments state.
2. All messages before the 'Sequence Number Reset' message are no longer available for retransmission by the Replay Server.
3. When the primary SDS is not responding, the FIX client should try to connect to the successive SDS provided by CQG. All SDS provide identical data and are interchangeable.
4. FIX clients use heartbeat messages to monitor the connection state.
5. The user sets the Heartbeat timeout through the 'HeartbeatTimeout' field (tag 108) in the Logon message (35=A).
6. When the primary Replay Server (RS) is not responding, the FIX client should try to connect to the secondary RS.