Try TT Now

All Gateways

Troubleshooting and Recovery

Verifying Connectivity

You can use both the Order Server log file and the TT.log file to verify the type of connection between the TT Gateway and client applications. The Order Server creates three messages when attempting to connect to the client application.

In the first message, the Order Server assigns a sequential connection ID when it attempts to connect to the client application. The Order Server writes an INFO message (10004601) which contains the client application’s IP address and port assignment and the assigned Connection ID.

Example Successful Connection Message

| INFO | 10004601 | Successfully opened a client connection for client _IB.K95609b5280319b88f97e2ae3a76c43.10.1.2.3.48 with a new connection ID of 1

This message above shows that the client application’s connection IP address and port assignment (10.1.2.3.48) and the assigned Connection ID (1).

The second message (10004602) verifies whether the client application connected via unicast or multicast.

Example Multicast Connection Message

| INFO | 10004602 | Connection (1) is connecting with the following traits: multicast OFX.

This message above verifies that the client application has connected via multicast.

Example Unicast Connection Message

| INFO | 10004602 | Connection (2) is connecting with the following traits: unicast VIA.

This message above verifies that the client application has connected via unicast.

Recovery

Upgraded TT Gateways and client applications recover from missing data, from either a disconnect or network issues, in the same way as older versions.

When a client application experiences a disconnect, the client application immediately reconnects to the TT Gateway and requests the missing data. The Gateway responds by synchronizing any missing fills with the client application.

Note

TT retained the existing recovery approach to remove the need for the client application to send negative acknowledge messages (NAKs) to the TT Gateway.

In a network with multiple LANs, each WAN Router uses the automatically configured TTM subjects to determine whether to filter or forward the data. This allows network segments that do not require the data to drop the additional traffic at the WAN Router without impacting their connected clients as shown in the diagram below:

In the preceding diagram, the following sequence occurs:

  1. An X_TRADER workstation in the New York LAN enters recovery and triggers an order book download by re-establishing a connection to the TT Gateway.
  2. The TT Gateway receives the request and forwards the requested data to the WAN.
  3. The WAN Routers in (a.) Houston and (b.) London filters the data based on the automatically configured TTM subjects. The WAN Routers disregard the data, leaving the connected clients in both locations unaffected.
  4. The New York WAN Router reads the TTM subjects and forwards the requested data to the affected client application.