These notes from Riley Rainey have now only an historical value and illustrate the motivation and the origin of the DIS library in ACM. The current ACM-5.0-ico solved the problem of site ID and application ID assignment in another way, then removing the need for a simx layer and the corresponding libraries and simx server; also RCP is not needed anymore making all a bit simpler. Also the data base of DIS is gone as it is not used anymore. [U.S.]
I have always been interested in distributed interactive simulations. In 1991, I released via Usenet a free X11-based multi-player air combat simulation which I had named “ACM”.
In the spring of 1994, Eyal Lebedinsky contacted me. He is the author of another freely available flight simulator, “fly8”. He introduced me to the IEEE DIS protocol and expressed interest in using DIS to integrate our two programs. He pointed me to the Naval Postgraduate School’s freely available DIS implementation, called NPSNET.
At the time I looked at it, the NPSNET DIS library is a reasonably complete, if somewhat literal implementation of the DIS protocol standard written for Sun and SGI UNIX systems. However, it had the significant portability drawback that it was written exclusively for big-endian machines. I set out to create a more functional and portable implementation but was quickly drawn back to work more directly related to my “real” job.
Early in 1995, I was contacted by Mats Loftkvist. Mats had independently taken the time to integrate a version of NPSNET into the current release of ACM. This prompted me to dust-off the work that I had dropped earlier and to begin considering in earnest how one might create an improved DIS interface.
My thinking is that a reasonably complete DIS library would automate these functions:
1. Allow for easy construction, transmission, reception and disassembly of DIS PDU’s. This implies that the library must standardize data structures that will correspond to all DIS PDU data structures.
2. Present the programmer with easy access to the wide variety of pre-defined DIS enumerated values.
Here is where I start to wish to go further than the NPSNET code:
3. Provide standardized mechanisms that will automatically generate values for many fields whose contents are defined to be outside the scope of the DIS protocol. For example, it would be nice to be able to supply application id field values (part of the simulation address structure) with little or no user-level coordination required.
4. Provide a mechanism that would allow an application to temporarily define new entity types. Those new entity types would have dynamically assigned enumeration values. Those temporary entity types could then be used by other applications.
5. Provide a mechanism to allow disparate DIS applications to share other simulation-related information. An example of this would be a database of all defined DIS entity types that could be queried at runtime to determine information about entities owned by other applications.
6. Implement the source code so that it is not big-endian specific.
7. Provide a mechanism to automate Dead Reckoning computation that might include the automated transmission of position updates.
My DIS library implementation is divided into three layers. Each layer is assigned a three or four character naming prefix. All subroutine calls and data structures belonging to a given layer have names that begin with the associated character prefix.
The lowest level layer is called simply DIS. It defines routines used to broadcast and receive PDU’s on the network, translating those PDU’s to and from PDU data structures defined in this library. Translation is performed through calls to ONC XDR library routines.
There are a number of details to the DIS protocol that are undefined. For example, no guidance is provided on how various user-defined fields (e.g. a DIS application id) are actually allocated. The implication seems to be that these values are manually allocated and distributed before an exercise begins. That method seems unusable in an environment where you’d like to insulate users from the details of DIS. To remedy this problem, I have defined a central simulation management server, SIM/x. Individual DIS applications may elect to consult that server to be assured to be getting appropriate values for these fields.
The middle, SIM/x, layer implements an interface to this central SIM/x server. Server requests are communicated via ONC RPC.
The top layer, called DIS/x, integrates the two lower layers in a manner that allows DIS applications to interoperate whether they are consulting a common SIM/x server or not. This layer is implemented in such a way that the runtime environment can be tailored (through various environment variables and special configuration files) to allow the use of automatic (SIM/x) or manual value allocation techniques.
Riley Rainey -- Dallas, Texas, August 15, 1995