Sent From: [log in to unmask]


John, You can have multiple instances of an RTIambassador. For example, your FederateAmbassador class might contain an RTIambassador as a data member. All communications with the RTI would then go through methods of that class. Then, if you instantiate multiple copies of your FederateAmbassador class, you would then have multiple instances of the RTIambassador. There should be nothing to preclude you from doing so. BC -----Original Message----- From: Fay John F Contr AAC/WMG [mailto:[log in to unmask]] Sent: Tuesday, June 27, 2000 1:44 PM To: SISO - Run-Time Infrastructure and Communications Forum Subject: RE: HLA Standards Changes for the Single-Process Federation There are two reasons for the single-process federation: reuse and policy. While the single-process federate cannot interoperate across multiple platforms (I think it can with some trivial changes and a connection to a standard RTI, but that is a different issue), its SOM and the HLA standard interface do provide great opportunities for reuse. And my application is within the US Department of Defense, so I have to operate under the policy that all models and simulations shall be HLA-compliant. The reason for not using an existing RTI is that they are all too slow. I am trying to simulate digital electronic circuits in more-or-less real time, with update rates of about a million per second. I believe that communicating from one process to another, and certainly from one platform to another, will slow an RTI down too much. Hence the solution in my paper: skip the interoperability and focus on reuse. I would be very interested in hearing some performance data from the Pitch RTI in single-platform mode and from the ``demo`` RTI in the Introduction to HLA book. I looked up Hougland and Paterson`s paper concerning SMOC (99F-SIW-057) and I don`t think it will fill the bill, unfortunately. SMOC is a middleware package that sits on top of the RTI rather than an RTI itself. The primary technical question at hand is how a method within an RTI ambassador object knows which federate invoked it and which federation it belongs to. For a federate ambassador this does not pose a problem. As Len Granowetter said, one simply creates a subclass of the RTI_FederateAmbassador class for each federate (this was the idea in the Interface Specification all along) and stick the pointers to the parent federate and federation in the subclass. Again as Len said, one definitely does not want to call the ``join federation`` function multiple times with the same federate ambassador object. The sticking point with the RTI ambassador is that it does not allow derived classes. A federate creates an instance of the RTI ambassador and invokes its methods to communicate with the RTI, but there is no information passed to these methods that will allow the RTI ambassador object to ``look back`` to its calling federate and identify it. HLA federations which do not mind the cost in time can use global variables and search through the list of federates every time a method is called, but for an update time of a microsecond or two this is simply too much effort. John F. Fay [log in to unmask]



To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=Z-ARCHIVE-SIW-CFI