Try TT Now

All Gateways

Product Table Replication

Overview

Certain events require that product tables be replicated across the network:

  • Guardian starts up and discovers no product tables on the local machine (this usually happens with clean installations)
  • You use Guardian to update the product table and then publish the changes to the Guard Server.
  • The exchange sends a product update to the TT Gateway.
  • You manually edit a product table (outside of the Guardian GUI) and then increase the sequence number of the product table.

The key mechanism of product table replication is the heartbeat that Guardian and Guard Server exchange with one another, because the heartbeat sent by the Guard Server contains the sequence number of its product table. The following sections show how Guardian uses this sequence number to determine whether it has the most recent product table. If you manually update a sequence number, Guard Server does not update its heartbeat until you restart it.

Guard Servers also exchange heartbeats and maintain the local product tables on their TT Gateway machines.

For further information on a product table's sequence number, refer to Header. For more details on Guardian heartbeats, refer to Heartbeat Architecture.

When no Product Tables Exist

Tip

If you want to download all current product tables from all Guard Servers on the network, simply delete all product tables in <root drive>:ttGuardianconfig. Then stop and restart Guardian.

For whatever reason, if Guardian is missing one or more product tables at start up (e.g., on a newly installed client), Guardian acquires the missing product tables in the following manner:

  • Guardian starts up for the first time.
  • Guard Server sends a heartbeat over the network.
  • Guardian receives the heartbeat from the Guard Server and finds the sequence number in the heartbeat.
  • Guardian looks for its sequence number. Because Guardian does not have a product table from this Guard Server, Guardian cannot find its own sequence number.
  • Guardian requests the product table from Guard Server.
  • Guard Server sends the product table to Guardian.
  • Guardian receives the product table from Guard Server.
  • Guardian records the fact that it received a product table to the DD.MM.YYYY.TTLOG file in <root drive>:ttLogfiles.

When the Exchange Updates a Product Table

Each TT Gateway behaves slightly differently after receiving product updates from the exchange. For processes specific to the TT Gateway, refer to the SAM for that TT Gateway. However the TT Gateway processes a product update, after the Guard Server receives the data, the following process occurs:

  • Guard Server writes the changes to the TT Gateway's product table and increments the sequence number by one.
  • Guard Server sends only the new data (i.e., the updates) to all available TT workstations running Guardian, and records the event to its DD.MM.YYYY.TTLOG file.
    Note

    Guard Server immediately sends out updates to prevent the network from being flooded or the TT Gateway from being inundated by requests from Guardian, which normally occurs when client applications realize they have out of date product tables.

  • Guardian receives the new data and updates its product table.
  • Guardian records this fact to its DD.MM.YYYY.TTLOG file.

When You Manually Update a Product Table

Warning

Do not make manual changes to the Product Table without direct TT assistance. Instead, use the Guardian interface to make changes to the product file.

If you manually edit a product table, you must do so on the actual TT Gateway that uses the product table. For example, if you want to edit TTProdTbl_CME-A_PROD.dat, you must do so on the TT CME-A Gateway; you cannot edit the product table used by the TT CME-B Gateway and expect it to get replicated.

When you manually update a product table, increment the sequence number by one, and then restart Guard Server, the following process occurs:

  • Guard Server sends out its next heartbeat according to its schedule. As normal, Guard Server includes its sequence number.
  • Guardian receives the heartbeat from the Guard Server and finds the sequence number in the heartbeat.
  • Guardian locates the sequence number in its product table.
  • Guardian compares its sequence number against the sequence number contained in the heartbeat.
    Note

    If Guardian's sequence number is equal to or higher than the sequence number contained in the heartbeat, this process stops here. Otherwise, continue to the next bullet.

  • Guardian requests the new product table from Guard Server.
  • Guard Server sends the product table to Guardian.
  • Guardian receives the product table from Guard Server.
  • Guardian records the fact that it received a product table to its DD.MM.YYYY.TTLOG file.

When You Update a Product Table Using Guardian

Before you can use Guardian to update product tables, you must perform an administrative login using either TTRISKXXXMGR or a TTADM account. For a list of administrator logins and their privileges, refer to Login Security. The login that you use must reside in the WUAS (or if you use TT User Setup, in the Login Server).

When you use Guardian to edit a product table, you do not need to do so on the particular TT Gateway that uses the Product Table. After logging into Guardian, you have access to the same set of product tables no matter the machine. After editing a product table, you must click Publish to save your changes and send them to the Guard Server for replication.

When you use Guardian to update a product table and then click Publish, the following process occurs:

  • Guardian writes its changes to its product table.
  • Guardian sends its updates to the Guard Server.
  • Guard Server receives the new product table.
  • Guard Server updates its product table and increments the sequence number by one.
  • Guard Server sends only the new data (i.e., the updates) to all available machines running Guardian and records the event in its DD.MM.YYYY.TTLOG file.
    Note

    Guard Server immediately sends out updates to prevent the network from being flooded or the TT Gateway from being inundated by requests from Guardian, which normally occurs when client applications realize they have out of date product tables.

  • Guardian receives the new data and updates its product table.
  • Guardian records this fact to its DD.MM.YYYY.TTLOG file.

Guard Server Replication

In addition to communicating with Guardian, Guard Servers also communicate with one another via the same heartbeat. As regards replication, if two or more TT Gateways have the same exchangename (i.e., TT MISS Gateways set up for hot failover), they compare each other's product table sequence numbers. If one of these numbers are not in sync, the Guard Server with the lower number requests the latest product table from the Guard Server with the higher sequence number.

Guard Servers running on TT Gateways with different exchangenames never sync product tables. For example, a Guard Server on eCBOT-A never synchronizes its product table with a Guard Server running on eCBOT-B.