Starting Multinode or Remote JFORCES Runs.

There are a host of reasons to start multinode or remote node FORCES runs including:

  1. Multinode runs are the standard for exercise support. A variety of machines can connect to a single simulation execution with different priviledges for White (Umpire), Blue or Red force controls. They will be given a unified synthetic environment with (in the case of Blue or Red players) access to only their assets and detection reports from only their sensors with relistically limited, corrupted (as modeled) and delayed information. The Umpire node is a special application that can view and control all assets. Additionally the Umpire node(s) has access to some System Controls not available to Red or Blue force players such as Clock Controls.

  2. Occassionally it is desirable to run the simulation on a separate platform than the graphical interface. The normal reason this is done is the scenario starts to display "erratically" when run on the same machine as the simulation. This typically indicates that the machine does not have the performance to run both the simulation and the interface at the desired speed.

  3. Finally, a user might want to attach to an ongoing batch simulation run just to see what's going on.

There are three primary methods to start a simulation on a machine that's not running the interface.

  1. Use the batch_run utility on the simulation server

  2. Start a run on the server machine and then kill the MMI, but don't select the "Kill 'em All" Option.

  3. Start the simulation manually (type " alias sim_test" on a command line to see how this is done. This is really only recommended for expert users and programmers).

Regardless of how the simulation is started, the method to attach is always to start the interface normally on another machine connected by Internet-type WAN or LAN, and select the "System Controls->Connect" option. Fill in the host (that's where the simulation is running) and the connection port that you specified when starting the simulation in whichever way you started it. Click on the "Execute" button and you should connect. To verify you've connected you can either wait for the "End of Initialization Received" message in the Message Area of the Master Controls. Or (if you're impatient) select "System Controls->Monitor Execution->Rcvr Monitor" and see if it's failing to connect to the specified simulation. This monitor provides you a viewport to the programmer diagnostics (which are stored in the /tmp directory if you ever need to access them) and, while cryptic, will help diagnose problems. Remember that you can not connect to a simulation until it is done initializing, so there could be a delay.

Common Problems:

Occassionally you'll not find the simulation listed on the host list provided in this interface. This list is created from the entries in the /etc/hosts file and the simulation server might not be identified in this file. The simplest way to connect in this case is to put the simulation server's IP address in the host entry widget (e.g. 207.225.107.10).

Sometimes you'll find that the seurity configuration of either the interface machine or of the simulation server prevents communications. Usually on systems in secure areas we run low system security, so this is not a problem. But if you're running in the open (internet) or otherwise have system security set high you might need to either install or configure a remote shell server. The primary candidate for this is secure shell (also known as ssh). Click here for configuration information. Alternately the firewall configuration might preclude access to the port. There are too many options for firewalls, so we will have to help you on this on a phone call basis. Be aware you need to open access not just on the primary connection port (e.g. 3000), but also on the next port up (e.g. 3001) for back communications from the simulation.