Selectively Reliable Multicast Protocol
|CTF||one of these:|
|Endpoint Name||Set to:|
hostname is the IP of the rtiexec (server)
port is for firewall opening (if necessary)
hostname is the IP of the rtiexec (server)
port is for firewall opening (if necessary) and
must be different from the rtiexec port.
|federate endpoint||IP of host machine running the gateway|
required only when firewall opening is needed
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
Use a separate command window for each of the following:
To start the CTF application, click on
Play Capture The Flag.bat
(yellow icon) in
Creating a shortcut of this batch file on your desktop is recommended.
To play more than one player on the same machine, click on
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 .
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 . 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
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.
The following are the ordered events in GMUGateway processing for DIS to HLA.
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
file. To run the GMUGateway through
SRMP, specify the transport mode for the objects and the interactions defined by users as
file. Users can use the
file already prepared
in the GMU_Gateway directory. Copy the proper file into the GMU_Gateway\gateway directory and rename
it as the
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:
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 .