TTM Network Administration Documentation
- What’s New In This Release
- TTM Overview
- Unicast And Multicast Network Communication
- Network Setup And Configuration
- Installing And Upgrading TTM And Guardian
- TTM Daemon
TTM Remote Host Daemon And Remote Clients
- Introduction to the TTM Remote Host Daemon
- Remote Mode: Pros and Cons
- Remote Mode Operations
- Network Considerations when Deploying the Remote Host Daemon
- Configuring a Remote Host Daemon
- Configuring the Remote Client
- Compressing Data
- Manually Configuring TCP Window Size
- Testing the Remote Connection
- Remote Host Daemon Failover (Disaster Recovery)
- Advanced Topics
- Maintenance And Troubleshooting
- Ttmd.cfg File Reference
Remote Mode Operations
Logging in Remotely
The typical login process undertaken by TT applications in remote mode is delineated below in the order in which it occurs:
- The user connects his machine (workstation or laptop) to the Internet using an ISP or to the Remote Host Daemon using direct dialup.
- If the trader has Virtual Private Network (VPN) connectivity, he runs the VPN.
- The trader launches the TT application (e.g., X_TRADER).
- The TT application connects to the Remote Host Daemon.
- The user logs onto the needed TT Gateway servers.
The Remote Mode Operation
Remote mode operates in the following manner:
- The Remote Client connects to the Remote Host Daemon using TCP only via the Internet or other low-speed interconnect.
- The Remote Client initiates all connections to the Remote Host Daemon.
- The Remote Host Daemon continues to use the default ports specific to the middleware employed (10200).
- The Remote Host Daemon sends price updates and other one-to-many messages to each client using Unicast. Thus, if the Remote Host Daemon must send 5 multicast messages to 5 remote mode clients, the Remote Host Daemon sends 25 messages (5 unicast messages to each client). For a detailed discussion on multicast and unicast communications as well as associated bandwidth utilization, refer to the topics listed under Unicast and Multicast Network Communication
To support remote mode connections, TTM automatically generates TCP heartbeats every 20 seconds. These heartbeats force simple network appliances on the Remote Client to maintain their PAT tables and keep alive the TCP connection even during extended periods of inactivity.
To conserve bandwidth, you can set the Remote Host Daemon to consolidate (i.e., Nagle) its price data before sending it over the TCP/IP connection to the various Remote Clients. Though Nagling increases network performance, it slows down price data distribution a little bit. To Nagle your price data, set the TcpNoDelay parameter (also called tcp_no_delay) in ttmd.cfg on the Remote Host Daemon. TTM also supports Accumulation, which has the benefits of Nagling with less of a delay.
Additionally, you can further decrease the amount of bandwidth that your remote mode solution uses by configuring your Remote Clients and Remote Host Daemons to compress their data before sending it over the network.
A Remote Host Daemon instance can support a maximum of 100 X_TRADERs for uncompressed systems, 80 for compressed systems, and 70 for encrypted systems.
For further details on remote mode data compression, refer to Compressing Data.
Failing Over Between Remote Host Daemons
When you deploy multiple Remote Host Daemons and set up your remote applications for failover, if the Remote Host Daemon fails, Remote Clients respond in the following manner:
- The Remote Client immediately detects the break in TCP/IP.
- The Remote Client attempts to connect to the alternative
IP address listed in the Daemon
Setup dialog box.
- If the Remote Client was connected to the Remote Host Daemon listed in IP Address (1), the Remote Client attempts to connect to the Remote Host Daemon listed in IP Address (2).
- If the Remote Client was connected to the Remote Host Daemon listed in IP Address (2), the Remote Client attempts to connect to the Remote Host Daemon listed in IP Address (1).
- If the Remote Client cannot connect to the alternative address, it begins a behavioral loop, attempting to connect to each IP Address (1 and 2) until it establishes a connection.
Another failover scenario involves a slow consumer condition. This occurs when the TCP / IP connection remains alive but the Remote Host Daemon does not read data sent from the remote application. In this case, the remote application begins storing its data in a send queue (approximately three MB in size). Once the Remote Client’s queue fills to 80% of its total size, it registers a slow consumer condition. At this time, the TTM daemon begins sending heartbeats to the Remote Host Daemon. If the Remote Host Daemon does not respond to the heartbeats for three consecutive minutes, the Remote Client assumes the connection has failed and attempts to connect to the alternative IP address listed in the Daemon Setup dialog box (refer to the second bullet above).