← Back to X_TRADER® Help Library

TTM Network Administration Documentation

Multiple Multicasts

Multiple Multicast Overview

When a TT network has a single multicast, that multicast carries price, order, fill, and heartbeat messages for every Gateway that has joined it. Adding additional multicasts allows you to divert some of the messages from the single shared (common) multicast onto multicasts that are dedicated to a Gateway or groups of Gateways.

To separate messages across multiple multicasts, you assign an approved list of TTM subjects to a specific multicast address. Your TAM can help you determine the best solution for your network and provide you with a list of subjects.


A TTM subject is a string of characters, usually segmented, that an application attaches to a message before sending it. If the subject is segmented, segments are separated from one another by periods. This subject defines the destination of the message. For example:


In this example, the subject ends in a Gateway Exchange ID, which is a static number assigned by TT. You can find the Gateway Exchange ID by locating the Gateway Exchange name in the ExchIds section of the ~ttconfigaconfig.xml file. In the above example, the Gateway Exchange ID is 699, which means that the subject applies only to the CME-Z exchange.

Supported Uses

Multiple multicasts are only approved for use in the following scenarios:

  • A Price Server with non-coalesced pricing can be assigned one multicast, while the coalesced Price Server is assigned another multicast. This is sometimes used in Autospreader SE environments.
  • A busy exchange Price Server can be assigned its own multicast. This improves network performance because the Price Server does not see price data from any other Price Server in any other market.

Separating messages onto multiple multicasts is an advanced task that should only be performed under the supervision of your TAM. Many TT messages are interdependent and cannot be separated, and some TT features use dynamically defined messages. Incorrectly configured multicasts could cause messages to be dropped.

Additionally, TT may rename, add, or remove messages at any time. Customers will only be notified of changes made to messages used in the supported multiple multicast scenarios.

Creating a Multiple Multicast Environment

To create a multiple multicast network environment, assign multicast group addresses to multicast subjects in the <MulticastGroups> section in the ttmd.cfg file (Guardian cannot be used to configure multiple multicasts).

To simplify configuration, you can copy the same ttmd.cfg file to multiple hosts (Gateways, X_TRADERs, FMDS, etc). The file can contain subject to multicast mappings for each host without affecting daemon performance or bandwidth. This is because each daemon ignores any subjects for which its host is not a sender or receiver, and only joins multicasts from which it receives subjects.

To create a multiple multicast network environment:

  1. Using a text editor like Notepad, open the ttmd.cfg file, located in <root drive>:ttconfig.
  2. In the <MulticastGroups> section, add multicast subjects for each Gateway that will connect to a separate multicast, and then assign the multicast subjects to a multicast. For example, price update messages for an exchange could be sent on one multicast, while price update messages for another exchange could be sent on a different multicast. When adding new multicast subjects, use the following syntax:



    Multicastsubject = MulticastGroupAddress

    Where Multicastsubject is a TTM subject that may or may not be appended with a Gateway Exchange ID, and MulticastGroupAddress is the IP address of the dedicated multicast to which the subject will be sent. For more information about TTM subjects, refer to Multiple Multicast Overview.

  3. Configure the last line in the <MulticastGroups> section to read: > = MulticastGroupAddress where MulticastGroupAddress is the IP address of the shared multicast. The > instructs the TTM daemon to send all messages not specified in this step to the defined MulticastGroupAddress. If you do not have this as the last entry in the <MulticastGroups> section, TTM generates an error on startup.

    The following example shows the ttmd.cfg file format.

    Example ttmd.cfg file multiple multicast format



    # Gateway #1

    [subject_1].[gateway exchange ID].> = [multicast]

    [subject_2] = [multicast]

    [subject_n].> = [multicast]

    # Gateway #n

    [subject_1].[gateway exchange ID].> = [multicast]

    [subject_2] = [multicast]

    [subject_n].> = [multicast]

    > = [MulticastGroupAddress]



  4. After making your changes, save and then close the file.
  5. Stop all TT Services and TTM, restart TTM, and then restart all TT Services.
  6. For an example of a configured ttmd.cfg file, refer to the Multiple Multicast Example.

Multiple Multicast Example

The following figure shows a multiple multicast environment. In this example, the Price Servers for the CME and ICE Gateways have been assigned separate multicasts, while the Eurex Gateway uses only the common multicast.

Multiple Multicasts

In this example, messages are sent and received as follows:

  1. The CME Gateway sends the price update messages for the CME-Z exchange (699) to the Globex Multicast.
  2. The CME Gateway sends all other CME messages to the common multicast.
  3. The ICE Gateway sends the price update messages for the ICE_IPE-Z exchange (757) to the ICE Multicast.
  4. The ICE Gateway sends all other ICE messages to the common multicast.
  5. The EUREX Gateway sends all messages to the common multicast.
  6. The CME, ICE, and EUREX Gateways receive all messages that are on the shared Customer multicast. The daemon for each Gateway ignores any subjects for which its host is not a sender or receiver.

The following example shows how the CME and ICE Gateways would be configured for the figure called Multiple Multicasts.

Example ttmd.cfg Example



# CME-Z Exchange

TTVIA.prc.upd.699.> =

TTVIA.prc.msg.699.> =

. . .

TTVIA.prc.ack.699.> =

# ICE_IPE-Z Exchange

TTVIA.prc.upd.757.> =

TTVIA.prc.msg.757.> =

. . .

TTVIA.prc.ack.757.> =


> =