Sent From: [log in to unmask]


Keith Briggs wrote: > >This comment has engendered a great deal of discussion on the RPR-FOM >reflector as a significant inconsistency between the published spec and >the most recent RTI version. The issue is clearly important for all RTI >users so I have cross posted the initial email that touched off the >debate. The full discussion can be accessed through the reflector >section of the SISO web site. > While this fact is a key issue, and important to be aware of and consider when developing FOMs (reference or otherwise), federations and interface software, but it is not an inconsistency between the IF Spec and the RTI. The latest IF Spec clearly states that Object instance handles are only required to be unique for loacl federate. The problem lies, not in that the RTI inaccurately reproduces the spec, but that this is a subtle, yet major change to the spec that people need to be aware of, and it hasn't been very well publisized. There is more impact due to this change than just requiring federates to comeup with their own global ids for their objects. You also have the problem of there being an indeterminate time between discovery and the update of whatever attribute contains the ojbect's global id. There are ways around this, but it is another impact that must be considered. (FYI: the area where RTI and IF Spec do differ is the discoverObjectInstance call which has a 'name' parameter that is not in the spec, but I believe that is an oversite in the spec and will be rectified in the next release) >Keith Briggs >RTI&C Chair >---------------- Begin Forwarded Message ---------------- >Date: 06/25 2:16 PM >Received: 06/25 4:07 PM >From: Randy Saunders, [log in to unmask] >Reply-To: SISO-RPR, [log in to unmask] >To: SISO - Plug and Play Family of Models, >[log in to unmask] > >>X-Sender: [log in to unmask] >>Date: Fri, 19 Jun 1998 22:10:12 -0400 >>To: [log in to unmask] >>From: Steve Bachinsky <[log in to unmask]> >>Subject: RPR FOM Object ID >>Mime-Version: 1.0 >> >>Randy, >> >>I was poking around the SISO site and came across some issues from the RPR >>group that you are involved with. I wanted to point out a particular >>implementation issue with the current RTI 1.3 implementation that may >>effect the "RTI Object ID" item. The object instance designator returned >>from the register object instance call is not unique to the federation, it >>is only unique to the federate. >> >>This means that within your FOM you can not pass around this object >>instance designator in object updates or interactions because it will be >>meaningless (or incorrect) to other federates. I do not know if the RPR FOM >>is using the RTI object instance designator for identification, but to work >>correctly it will need to ask for the object name. The problem with the >>name is that it is a string which is less efficient for storage and >>comparison operators. >> >>In my opinion this is a flaw in the implementation and specification. The >>legacy of the problem goes back to STOW when they did not want to have any >>centralized component of the RTI to hand out ids, and the scheme for unique >>ids was to concatenate four longs to generate an almost unique number. >>[Only issue here is that 128 bits is enough to provide 10^23 addresses for >>every square meter over the surface of the earth.] >> >>I plan on including this issue on the next round of HLA SDG comments. >> >>Steve >> >>--------------------------------------------------------------- >> Steve Bachinsky voice: 703-333-5428 >> SAIC fax: 703-354-5398 >> 5400 Shawnee Road, Suite 110 pager: 888-347-1355 >> Alexandria, VA 22312 [log in to unmask] >> email: [log in to unmask] >>--------------------------------------------------------------- >> >/Randy Saunders >Raytheon Training Services >+1 (248) 619-8321 >[log in to unmask] > >----------------- End Forwarded Message -----------------



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