MTO

The MUSCLE Transfer Overlay (MTO) is a daemon for forwarding traffic from MUSCLE 2. This service is often required when MUSCLE 2 must communicate between several sites with firewall restrictions. On each site, a MTO should be placed on a node that is accessible within the cluster and from the outside world. Often, clusters have an interactive node that is suitable for this purpose. At least one of the interactive nodes should be able to accept connections from outside the cluster, the other interactive nodes only have to be able to connect to another cluster.

If MTO is already installed, set up, and connected between all relevant sites (see the next paragraph), all that is needed from MUSCLE to use the MTO is to add the --intercluster flag to the command-line:

muscle2 -mc model.cxa.rb --intercluster sub1

The address that the simulation manager prints (suppose its 10.0.0.200:5002) can then directly be used on another site:

muscle2 -c model.cxa.rb --intercluster -M 10.0.0.200:5002 sub2

For convenience, the --intercluster flag has the shorthand -i.

Configuration files

Before running MTO, its configuration files must be set to connect all clusters that will be used in a simulation. MTOs configuration is stored in three files:

• The global topology file ($MUSCLE_HOME/etc/mto-topology.cfg) states what clusters will be connected by the MTO and on which port it will listen for connecting MTOs. The file should be the same for all participating MTOs. Not all MTOs need to listen for connections, but at least one host should. Having few hosts listening may cause a performance penalty, since data may need to be routed through a third MTO to arrive at their destination.

// Comment
# Comment

# Host definition:
# <name> <address> [<port>]
# If the port is omitted, this MTO will not listen for incoming connections.

A localhost
B localhost 5100
C localhost
D localhost 5300

• The local configuration file ($MUSCLE_HOME/etc/mto-config.cfg) states how the MTO can be contacted by MUSCLE 2 within the cluster. It also specifies a limited port range on a given cluster, which should be different for each participating cluster. The internalAddress may be set to an IP-address or hostname that is accessible from all nodes in the cluster. If the host has multiple internet interfaces, the wildcard address * may also be specified here. For example, the wildcard is useful for aliasing the hostnames localhost and the fully qualified domain name and for running the MTO in a virtual machine.

# Name of this MTO as in mto-copology.cfg
myName = A

# Port range for clients of this MTO
# Clients may register listening ports only from this range.
# This range must not overlap any other MTO's range.
localPortLow    = 5002
localPortHigh   = 5099

# Port and address where this MTO will listen for client requests.
# Port and address for other MTO's is located in the topology file.
internalPort    = 5001
internalAddress = private-address

• The MUSCLE 2 configuration ($MUSCLE_HOME/etc/muscle.defaults) makes the information about the local MTO available to MUSCLE 2. This should match the local mto-config.cfg file.

# Make the MTO available to MUSCLE.
export MUSCLE_MTO=private-address:5001
export MUSCLE_PORT_MIN=5002
export MUSCLE_PORT_MAX=5099

Whenever $MUSCLE_HOME/etc/muscle.profile is sourced, these environment variables are set. If a wildcard address was set in mto-config.cfg, a definite address still needs to be set for the MUSCLE_MTO variable.

Starting MTO

The MTO can be started in two modes:

• debug mode

   mto --debug

• daemon mode

  mto

In the debug mode the MTO prints debug information and stays active in the console. In the daemon mode, it runs in the background and will continue after you log out. Instead of printing debug information, it will log some runtime information to a log file. The path of that log file is printed before going into daemon mode, but it can also be specified. Run

mto --help

to see all options.

To use multi-channel communication between sites, use the --MPWPath option. If used, this option must be enabled for all MTO's in an MTO topology.

Example setup

Suppose we are using two domains, Amsterdam.nl (IP: 50.50.50.50) and Poznan.pl (IP: 100.100.100.100). For the former, we use port range 5000-5999, and it does not have any open ports; it can contact the latter, with local port range 6000-6999 and an open port 20300. Then the global topology becomes

# <name> <address> [<port>]
Ams amsterdam.nl
Poz poznan.pl 20300

In Ams, we have the local configuration

myName = Ams
localPortLow    = 5002
localPortHigh   = 5999
internalPort    = 5001
internalAddress = 50.50.50.50

And in Poz, the configuration becomes:

myName = Poz
localPortLow    = 6002
localPortHigh   = 6999
internalPort    = 6001
internalAddress = 100.100.100.100

For this configuration to work, on Ams, port 5001 must not be used by another process and on Poz, port 6001 and port 20300 must be available.