Synthetic Strategy Engine Documentation
- Product Description And Architecture
- Installing The Synthetic SE Software
Configuring Synthetic SE
- Types of TT Synthetic SE Deployments for Market Data
- Configuration Files for 7.17.1 or Higher
- Configuration Files for 7.17.0
- Configuration Files for 7.3.X
- Configuring Synthetic SE with Dynamic Connections Enabled
- Determining TT Gateway Login Credentials with Dynamic Connections Disabled
- Configuring the Synthetic SE Fill Server
- Configure: Single-Multicast Network with Only Non-Coalesced Price Servers
- Configure: Single-Multicast Network with Coalesced and Non-Coalesced Price Servers
- Configuring a Multiple-Multicast Network
- Order Staging
To ensure continuity of trading activity during Synthetic SE outages, Synthetic SEs should be configured in redundant pairs. This section discusses configuring your environment to support redundant Synthetic SEs.
To maximize performance and reduce latency, TT recommends that you use the following guidelines when configuring a network that supports the TT Synthetic Strategy Engine:
- Locate both the primary TT Synthetic Strategy Engine Server and the TT Gateways geographically close to the associated Exchange
- Locate a secondary TT Synthetic Strategy Engine Server and TT Gateways in an alternate geographic location.
- Configure X_TRADER to log into both the primary and secondary Synthetic SE Servers and into only the primary TT Gateway.
The following illustrates a sample deployment for primary and secondary TT Synthetic Strategy Engine Servers to support trading synthetic orders on CME. Because the CME matching engine is located in Chicago, you install a TT CME Gateway (CME-A) and the Synthetic SE Server (SSE-A) in Chicago for normal trading. To provide alternate access in the event of a lost connection, you install a secondary Synthetic SE Server (SSE-B) and a redundant TT CME Gateway (CME-B) in an alternate location.
In this recommended deployment, you should:
- Configure the connections between the Synthetic SE Servers
for the TT Gateways as follows:
- For SSE-A, select CME-A as the primary and CME-B as the secondary TT Gateways
- For SSE-B, select CME-B as the primary and CME-A as the secondary TT Gateways.
- Configure X_TRADER to:
- Log into the primary and secondary Synthetic SE Servers.
- Log into only the primary TT Gateway (CME-A).
For more information about configuring Synthetic SE Servers, refer to the topics listed under Configuring Synthetic SE .
During Normal Trading
The following illustration shows how orders flow during normal trading, when a trader can access the primary Synthetic SE Server (SSE-A) and the primary TT CME-A Gateway.
- X_TRADER submits synthetic orders for instruments on CME-A to SSE-A.
- SSE-A sends the child orders to the TT CME-A Gateway at the appropriate time.
- CME-A submits the child orders to the CME Host.
When X_TRADER Loses Its Connection to the Primary Synthetic SE Server
Suppose X_TRADER loses its connection to the primary Synthetic SE Server (SSE-A) in Chicago. The following illustration shows how the message path changes to re-route orders through the secondary Synthetic SE Server (SSE-B).
- X_TRADER begins routing orders through SSE-B in the alternate location.
- SSE-B sends the synthetic orders for instruments on CME-A to TT CME-A Gateway in Chicago, because SSE-B is configured as the backup Synthetic SE Server for the TT CME-A Gateway.
- When SSE-A becomes available again, X_TRADER resumes submitting synthetic orders through its primary Synthetic SE Server, SSE-A.
By logging into both the primary and secondary Synthetic SE Servers, X_TRADER can automatically switch to the secondary Synthetic SE Server with no trader intervention.
If Synthetic SE crashes, it will be automatically be restarted by TTChron. In this scenario, all synthetic orders will resume if they can be reconciled.
If Synthetic SE cannot be restarted, you need to decide whether to delete or leave any child orders working in the market. You must also reenter all synthetic orders that were working on the primary Synthetic SE; these orders will be routed to the secondary Synthetic SE. In addition, you must direct a TT system administrator to delete the Synthetic SE synthetic order persistence files (root:ttdatfilesSSE_Persistence_*).
If you do not delete the Synthetic SE persistence files, Synthetic SE will attempt to resume all synthetic orders when it is restarted.
When X_TRADER Loses Its Connection to the Primary TT Gateway
Suppose that X_TRADER loses its connection to the primary TT Gateway (CME-A) in Chicago. Traders can no longer trade CME-A instruments, so must they log into the secondary TT Gateway to route orders. The following illustration shows how the message flow changes to route orders through the secondary TT Gateway (CME-B).
- The trader logs into the TT CME-B Gateway located in the alternate location.
- X_TRADER starts routing orders through SSE-B in the alternate location, because SSE-B is configured as the primary SSE Server for the TT CME-B Gateway.
- SSE-B sends the synthetic orders to the TT CME-B Gateway.