MENU

SRMP Home

DIS-HLA Gateway
Gateway Download

NGI-FOM with SRMP
Demo Configuration

Publications

NetLab Home

Selectively Reliable Multicast Protocol
DIS-HLA Gateway Documentation

Contents

• Overview
• Class Paths
• Software Download
• Software Configuration
• Software Execution
• Gateway Mapping
• Gateway Process Flow
• Differences: SRMP-RTI vs TCP-RTI

Overview

GMUGateway is a protocol translator developed in Java for distributed simulations. It provides interoperability among the different types of simulation architectures. The current version of GMUGateway converts Distributed Interactive Simulation (DIS) protocol to High Level Architecture (HLA) Run-Time Infrastructure (RTI) service calls, and vice versa. It is specific to the NPS DIS-Java-VRML implementation (on the DIS side) and the RPR-FOM (on the HLA side).

Using GMUParser, GMUGateway reads a configuration file and retrieves necessary information for the GMUGateway configuration. This information includes IP address and port numbers receiving packets from or sending packets to. The configuration file is written in the Q-XML language which is a Quality of Service (QoS) and Configuration Specification Language.  Q-XML is easy to use, able to express the full range QoS requirements and configuration information, and compliant to XML, an evolving standard for information representational languages.  GMUParser uses XML Parser for Java from IBM AlphaWorks.

After setting up the configuration, GMUGateway creates an HLA RTI federation and joins the federation as a federate, and then  it translates from DIS to HLA and from HLA to DIS.  For the translation from DIS to HLA, it publishes the types of objects and interactions it will generate to the federation, and continuously receives packets from a specified IP address and port. It generates objects or interactions according to the types of the DIS Protocol Data Units (PDUs) into the federation. For the translation from HLA to DIS, it subscribes the types of objects and interactions it will receive, and whenever it receives a service call to reflect  the attribute values of a registered object or an interaction, it creates a DIS PDU with a corresponding type, and sends it to a specified IP address and port.

Path and Classpath Variables

Path:
.;
C:\vrtp;
C:\RTI\Winnt-4.0-VC6\bin;
C:\RTI\Winnt-4.0-VC6\lib;
C:\jdk1.3.1\bin;
C:\jdk1.3.1\lib;

Class path to run GMUGateway:
.;
C:\vrtp\dis-java-vrml.jar;
C:\RTI\Winnt-4.0-VC6\hla-rti13-java1.jar;
C:\RTI\Winnt-4.0-VC6\gmuGateway.jar;
C:\ProgramFiles\CosmoSoftware\CosmoPlayer;
C:\XML4J-3_2_0\xerces.jar;
C:\XML4J-3_2_0\xercesSamples.jar

Class path to compile the source code of GMUGateway:
.;
C:\vrtp\dis-java-vrml.jar;
C:\RTI\Winnt-4.0-VC6\apps\JavaBinding\apps\GMU_Gateway\source;
C:\ProgramFiles\CosmoSoftware\CosmoPlayer;
C:\XML4J-3_2_0\xerces.jar; C:\XML4J-3_2_0\xercesSamples.jar

Software Download

For running the complete application, the following software is required:

CTF requires the following software:

The multicast IP and port used by the CTF are hard coded in the vrtp application. All the files which use the IP and port are modified and there are 4 versions of vrtp using different multicast IPs and ports.

The multicast IPs / ports chosen are :
224.2.181.145 / 62040
224.2.181.149 / 62049
224.2.181.199 / 31329
224.2.181.196 / 31326

This software is available for download at:
http://netlab.gmu.edu/~mparupal/Gateway

Software	Download
RTI	RTI.exe
SRMP	SRMP.exe
XML	SML4J-3_2_0.exe
CTF	one of these: vrtp224.2.181.145.exe vrtp224.2.181.149.exe vrtp224.2.181.199.exe vrtp224.2.181.196.exe

After unzipping the CTF executable, rename the folder vrtp.
All the executables must be unzipped into the C:\ drive.

Software Configuration

• RTI.rid file in C:\RTI\Winnt-4.0-VC6\apps\JavaBinding\apps\GMU_Gateway
  on all the machines on which a gateway is run should be consistent except
  for the federate endpoint value.
• Set 3 endpoints:

We can use either TCP or SRMP for the transport protocol by specifying the transport mode for each attribute of objects or interactions in the DIS-HLA.fed file. Users can just copy the file corresponding to the transport protocol into gateway directory, and rename it as DIS-HLA.fed.

The two files are tcp_DIS-HLA.fed and srmp_DIS-HLA.fed and are found in the C:\RTI\Winnt-4.0-VC6\apps\JavaBinding\apps\GMU_Gateway directory. To compare the performance of SRMP and TCP, we use these files alternately and record the number of bytes sent in specified time period. These statistics are written into srmp_bytes_sent.txt and tcp_bytes_sent.txt found in
C:\RTI\Winnt-4.0-VC6\apps\JavaBinding\apps\GMU_Gateway\gateway .

Software Execution

Use a separate command window for each of the following:

1. Start SRMP:
   C:\srmp\debug> srmp
   
   
2. Start RTI Server:
   C:\RTI\Winnt-4.0-VC6\bin> rtiexec -endpoint serverhost:port
   or use server_start batch file in C:\RTI\batch_files directory.
   (The endpoint for the server in the batch file should be updated properly before using it.)
   
   
3. Start GMUGateway:
   C:\RTI\Winnt-4.0-VC6\apps\JavaBinding\apps\GMU_Gateway\gateway> java gateway/gmuMain DIS-HLA
   or use gmu_gwstart batch file in the C:\RTI\batch_files directory.
   
   You can run multiple gmuGateways on a system. To do so, copy the gateway directory under GMU_Gateway directory, and name the new directory with different name. Then modify the all configuration files in the directory properly. You will also have to modify the directory names in the gmu_gwstart batch file.
   
   
4. Start DIS application:
   

CTF

To start the CTF application, click on Play Capture The Flag.bat (yellow icon) in
C:\vrtp\demo\helicopter
Creating a shortcut of this batch file on your desktop is recommended.

To play more than one player on the same machine, click on Player Select.bat in
C:\vrtp\demo\helicopter.

DIS Loader

This DIS application produces PDUs at a rate to test the load capabilities of the configuration. At 33 megs, it's a little on the large side, but that is because it includes
the Java JRE, Java3D, GL4Java, and everything else you need to run NPSNET-V.

You can download it from http://www.movesinstitute.org/~kapolka/installer.exe

When DIS Loader is installed, it creates a shortcut for the NPSNET-V browser and puts it in the Program Files directory.To run the shark test, open the browser, then go to File/Open/Browse Files, and select load_test.xml from the install directory.It will take a few seconds to load.To see the output, click View/Java Console. Every five seconds, you should see a report of the average incoming and outgoing packet and data rates.The incoming rate represents the total traffic on the group, since it includes the looped-back packets.

The outgoing packet rate corresponds heavily to the frame rate, so you can
adjust it to some extent by turning the camera towards or away from the sharks. Change the multicast address or port, if necessary, by editing load_test.xml .

Gateway Mapping

GMUGateway maps the PDUs of the DIS software to the Objects/Interactions of the HLA software and vice versa.

Though many kinds of DIS PDUs have been specified, the NPS software DIS-Java-vrml application does not support all DIS PDUs. The PDUs supported by the NPS software are well documented in DIS-Java-VRML Javadoc . Use the link for the PDU name in the list of classes to see the details of the fields and methods associated with your chosen class. For example, to see the values used by fields of EntityStatePdu, use the link EntityStatePdu and the fields and methods for that PDU will be displayed. All PDUs supported by NPS software are handled in GMUGateway.

The way PDUs are mapped into HLA objects/interactions, is explained in detail in Institute for Simulation and Training, HLA Gateway Release 2.1
User Guide IST-TR-97-08

See DIS-HLA.fed in
C:\RTI\Winnt-4.0-VC6\apps\JavaBinding\apps\GMU_Gateway\gateway
for details about the various objects/interactions of RPR-FOM that are supported by GMUGateway. Any new PDUs to be supported and corresponding object classes should be added in this file.

Gateway Process Flow

The following are the ordered events in GMUGateway processing for DIS to HLA.

1. The first gateway instantiated creates the federation and joins the federation.
   Subsequent gateways instantiated will then join the federation.
2. The first gateway initializes the RTI simulation handles for the list of classes;
   Only the objects of these classes can be published/subscribed.
3. Every PDU received by the gateway is checked for the EntityID.
4. Depending on the PDU field values, corresponding HLA object is created. For example, if the PDU is pduType ESPDU, (the type of the PDU is determined by pduType field in the ProtocolDataUnit class) the gateway will create an object of leaf class of BaseEntity. There are several subclasses derived from BaseEntity class, like MilitaryAirLandPlatform and MilitaryLandPlatform. The leaf class to be instantiated is determined by the value of the entityDomain field in the ProtocolDataUnit class. If the entity playing is helicopter for example, MilitaryAirLandPlatform object is instantiated. The hierarchy of the classes and which class object corresponds to which PDU, is well explained in gateway documentation cited above.
5. If the entity ID is not already present in the hashtable which stores the RPR-FOM objects with the key of the EntityID, the gateway creates the corresponding object. If the entity ID is present, it calls the object attributes update method.
6. The object attributes update method sends the packet details to the federation. As the gateway has already published those objects to the federation, the federates which subscribed for them receive the updated values of the packets. The updates are accomplished by call back functions provided by RTI software, not the gateway.
7. If any exceptions occur or when the application closes, the gateway resigns the federate from the federation. The last federate to resign destroys the federation.

Running GMUGateway with SRMP or with only TCP

We can run the GMUGateway through only TCP or as SRMP using the RTI modified to integrate with SRMP. To run the GMUGateway through only TCP, specify the transport mode for each attribute of all objects and the transport mode for all interactions as reliable in the DIS-HLA.fed file. To run the GMUGateway through SRMP, specify the transport mode for the objects and the interactions defined by users as best-effort in the DIS-HLA.fed file. Users can use the tcp_DIS-HLA.fed or srmp_ DIS-HLA.fed file already prepared in the GMU_Gateway directory. Copy the proper file into the GMU_Gateway\gateway directory and rename it as the DIS-HLA.fed file.

In the project to integrate RTI and SRMP, we specify best-effort for transport mode to use SRMP for the user defined objects and interactions. Best-effort mode specified in the DIS-HLA.fed file makes RTI use the multicast channel to transport the corresponding data. Reliable mode specified in the DIS-HLA.fed file makes RTI use TCP channel. The multicast channel is where SRMP is plugged in.

In the gateway application we write transport mode ID and corresponding transport mode into srmp_mode.txt. For the object attribute case, transport mode ID is the hash of object class handle and attribute handle. Transport mode is 0 or 1. 0 for SRMP mode 0 and 1 for SRMP mode 1. In the interaction case, transport mode id is the interaction class handle and transport mode is 10 or 11. 10 is for SRMP mode 0 and 11 is for SRMP mode 1. We do not use 1 or 0 in interaction case but use 10 or 11, since we have to distinguish an object transaction or an interaction transaction inside RTI. If it is an object transaction, we store the dataID in the sorted array and register it with SRMP. Once a dataID is registered we will not register it again to SRMP. Since objects are persistent, unlike interactions, whenever we receive object transaction, we do a binary search over the sorted array and if the dataID exists, we do not reregister with SRMP. If it is an interaction transaction, we register dataID to SRMP, but do not save the dataID in the array. Since every interaction has a distinct dataID, interaction instance count is unique for every interaction.

When we send data through SRMP, we need dataID and transport mode. DataID in object transaction case is a hash of object instance id and attribute handle. For the transport mode, at RTI level we regenerate transport mode id. (This is possible since we have object class handle and attribute handle available at RTI level.) Then we look up srmp_mode.txt and find the transport mode.

RTI reads srmp_mc_addr.txt in
C:\Winnt4.0-VC6\apps\JavaBinding\apps\GMU_Gateway\gateway to send data to or to receive data from the multicast address. RTI registers and signs on with the multicast address to SRMP. SRMP will listen to that multicast address. If any incoming message is on that multicast. address, it delivers to RTI.

Changes made in RID file:

PARAMETER:
FederationSection.DataDistribution.StrategyToUse
(StrategyToUse Simple)

PARAMETER:
FederationSection.Networking.BundlingOptions.UDP.MaxTimeBeforeSendInSeconds
(MaxTimeBeforeSendInSeconds 0)

PARAMETER:
FederationSection.Networking.BundlingOptions.UDP.MaxBytesBeforeSend
(MaxBytesBeforeSend 0)

PARAMETER:
FederationSection.Networking.BundlingOptions.TCP.MaxTimeBeforeSendInSeconds
(MaxTimeBeforeSendInSeconds 0)

PARAMETER:
FederationSection.Networking.BundlingOptions.TCP.MaxBytesBeforeSend
(MaxBytesBeforeSend 0)

PARAMETER:
FederationSection.Advisories.AttributeScopeAdvisories.LazyObjectDiscovery
(LazyObjectDiscovery Enabled)


Changes at application level :

We do not want RTI to bundle the various update transactions or interactions because SRMP does the bundling. We write the transport mode of each attribute of objects and interactions defined by user into the srmp_mode.txt file. When we send the data of an object, we send the whole attribute set (objectclass.update method) only when we receive data about a new object (DIS Entity). After that, with every update, we send out only the attribute values updated as best-effort data one by one and reliable as a bundle (objectclass.update_check method). When attributes are bundled, in RTI level, it checks the hash of first attribute handle and the object class handle for the transport mode .