Print

Print


RE: Creating and Destroying Federations Geoff Barbier <a href="/index.htm?LOGON=A3%3Dind0207%26L%3DZ-ARCHIVE-SIW-CFI%26E%3Dquoted-printable%26P%3D98961%26B%3D--%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26XSS%3D3%26header%3D1" target="_parent" >[log in to unmask]</a> <a href="/index.htm?LOGON=A3%3Dind0207%26L%3DZ-ARCHIVE-SIW-CFI%26E%3Dquoted-printable%26P%3D98961%26B%3D--%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26XSS%3D3%26header%3D1" target="_parent" >[log in to unmask]</a>
Mr Bryden,

I`m sincerely and respectfully curious... If this is not the kind of
discussion we can expect to see on this reflector, what is the reflector
for?

Best Regards,

Geoff

Geoffrey Barbier
[log in to unmask]
(480) 988-6561 ext.162
Systems Engineer, Simulation Technologies Inc.
A&AS Support for:
AFRL/HEA - Warfighter Training Research Division
-----Original Message-----
From: Bryden, Kevin [mailto:[log in to unmask]]
Sent: Friday, July 19, 2002 1:26 PM
To: SISO - Run-Time Infrastructure and Communications Forum
Subject: RE: Creating and Destroying Federations

Staying informed how this problem/solution is evolving is good.  Although I
would raise the question if problems and their associated solutions/ideas
are to be solved on the reflector.  If so then I`ll bear with it and remove
the emails.  But I have not seen these type of discussions occur on the
reflector over the past 6-8 months.  Is it possible to move this discussion
to an email distribution list of those interested or a SISO/RTI
discussion/Q&A board.

-----Original Message-----
From: Len Granowetter [mailto:[log in to unmask]]
Sent: Friday, July 19, 2002 4:17 PM
To: SISO - Run-Time Infrastructure and Communications Forum
Subject: Re: Creating and Destroying Federations



``Barclay, Nathan`` wrote:

> In regard to the idea of a special ``InitializeRTI* type call, I agree that
> adding calls that would have to be taken out in switching to a different
RTI
> is far from ideal.  But at least if the RTI offered that option,
developers
> could decide for themselves which poison is worse - designing a federate
> that requires changing one line to run with a different RTI or designing a
> federate that has to behave differently from how they want because the RTI
> doesn`t give them a choice.  Consider the following:

I think a third option would give us the best of both worlds: We can
provide an optional fedFileNameForLightweightMode RID parameter to let
you set the FED file name for lightweight mode.  That way, you can write
the code the way you want (without calling createFederationExecution),
and it will work in both modes without having to conditionally compile.
When you switch to lightweight mode, the RTI will automatically use the
FED file indicated in the RID.  I kinda like this scheme, and I think
I`ll put it on our to do list.

					-Len

> (1)  As long as ``InitializeRTI`` is merely an alternative available for
those
> who prefer not to call create, nothing is lost for people who want
federates
> that call create and can run under other RTIs without modification.
> (2)  In the absence of a separate initialize call, federate behavior that
> calls for not trying to create the federation execution cannot be
prototyped
> at all.  That`s a lot worse than being able to prototype such behavior at
> the cost of having to comment or uncomment a single line of code when
> changing between RTI versions.
> (3)  At least with the C API, a line along the lines of
>        define RTI_NG_LIGHTWEIGHT_MODE
> in the RTI header file would allow programmers to handle InitializeRTI
with
> code like
>        ifdef RTI_NG_LIGHTWEIGHT_MODE
>           InitializeRTI{};
>        endif
> so no code modification would be necessary under a different RTI.  And
> within an RTI implementation, providing a null stub for InitializeRTI in
> compliant mode could avoid the need for even that.
>
> In general, I like for the software I use to give me the flexibility to
> choose for myself how to do things instead of trying to dictate to me.
Even
> if the software designers are right about what`s best 99 times out of 100,
I
> want the flexibility to do things my way the other one percent of the
time.
> I know there are limits to how much flexibility it is practical to offer.
> But decoupling ``create`` and ``initialize`` and then having ``create`` call
> ``initialize`` if it hasn`t been called already seems like such a simple
thing
> to do that it`s hard to find a good reason not to do it that way.
>
> Nathan Barclay
>
> -----Original Message-----
> From: Keith Snively [mailto:[log in to unmask]]
> Sent: Friday, July 19, 2002 12:27 PM
> To: SISO - Run-Time Infrastructure and Communications Forum
> Subject: RE: Creating and Destroying Federations
>
> At Friday 12:27 PM 7/19/2002, Barclay, Nathan wrote:
>
> >For a lightweight mode, it seems like it could be useful to offer an
> >``InitializeRTI`` call that provides a way to read the FED file and do any
> >necessary initialization without having to risk creating the federation
> >execution in the process.  That would go outside the IF Spec, but at
least
> >it wouldn`t rewrite the semantics of a call that is part of the IF Spec.
>
> This is true, and I`ll grant that it may be less confusing to have a
> separate method since the behavior is slightly different.  However, our
> rational for not doing this is it starts to make federates dependent on a
> specific RTI implementation, or even a specific mode of operation of a
> specific RTI implementation.  As Len Granowetter stated, connectionless
> (lightweight) mode, among other advantages, may aid in rapidly prototyping
> a federate.  In order for this to work, it is important to ensure that any
> federate developed using this special mode will also work when the RTI is
> run in a standard compliant mode.  Having a federate call create before
> calling join will always work with RTI-NG in the standard HLA compliant
> mode.
>
> BTW:  According to the ``HLA Conformance Guide``, version 1.3 (draft 1)
dated
> April 15, 1998, which is the latest version posted on the DMSO web site at
> http://hlatest.msiac.dmso.mil/HLATest_1_3/htdocs/test_lib.html:
>
> ``Federate Interface Testing is not dependent on a federation. However,
> because Create Federation and Join Federation are mandatory services, the
> FUT (Federate Under Test) must create and join a federation in order to
> conduct Federate Testing.``
>
> I realize that the HLA specification does not require the call to create,
> but it appears that the federate compliance testing procedures do.
>
> >-----Original Message-----
> >From: Keith Snively [mailto:[log in to unmask]]
> >Sent: Friday, July 19, 2002 8:49 AM
> >To: SISO - Run-Time Infrastructure and Communications Forum
> >Subject: RE: Creating and Destroying Federations
> >
> >
> >I can speak to RTI-NG on this issue.
> >
> >Staring with version 6 of RTI-NG (Due out the end this month), the RTI
can
> >be placed into a ``connectionless`` mode.  Using this setting, no reliable
> >connections are made between federates and there are no centralized
> >processes, such as the rtiexec or fedex.   Certainly, this is a
> >non-compliant mode for the RTI, however offers a light weight, high
> >performance  capability for those federations which do not use any of the
> >services lost as a result of not having reliable connections, such as
time
> >management.  Federates that wish to run in this mode must first call
> >createFederationExecution before joining the federation in order to read
in
> >the FED file.
> >
> >The compliant, out-of-the-box configuration for RTI-NG does not require
the
> >call to create as long as the federation already exists.  In this case,
the
> >fedex process stores the FED file and joining federates will retrieve it
> >from that process.  However, I was under the impression that for a
federate
> >to certified as HLA compliant, that it must call create before calling
> >join.  Does anyone know if this is or is not a requirement for
> >certification?
> >
> >Keith
> >
> >At Thursday 09:51 PM 7/18/2002, you wrote:
> >
> > >Are you referring to current RTIs, older ones, or some of each?  I can
> > >understand why someone first trying to get an RTI working might take
that
> > >kind of shortcut, but I really don`t think an RTI that behaves that way
> > >ought to be regarded as compliant.  Basically, such an RTI is modifying
> the
> > >semantics of ``Create Federation Execution`` to make them something other
> >than
> > >what the Interface Specification says.  Federates should not have to
risk
> > >creating a federation when they don`t want to just to initialize!
> > >
> > >Suppose a federate designer wanted to take advantage of the Interface
> > >Specification`s design to have a federate operate continually in
standby
> > >mode attempting to join a federation (if it exists) every second or so.
> > >Unless I`m forgetting something, that ought to be possible, with the
> > >federate getting exceptions on the join operation until someone creates
> the
> > >federation execution.  But with ``create to initialize`` semantics, it`s
> hard
> > >to imagine how even one such federate could be built successfully, and
I
> > >can`t see at all how several could coexist peaceably in the same
> >federation.
> > >
> > >Nathan A. Barclay
> > >Teledyne Brown Engineering
> > >
> > >-----Original Message-----
> > >From: William K. Andrews [mailto:[log in to unmask]]
> > >Sent: Thursday, July 18, 2002 7:54 PM
> > >To: SISO - Run-Time Infrastructure and Communications Forum
> > >Subject: Re: Creating and Destroying Federations
> > >
> > >
> > >One thing to keep in mind is that some RTIs require the creat attempt
as
> > >that is how/when they parse the FED file.  Without the create attempt,
> they
> > >will not fully function.  Not all of them work this way, but several
do.
> > >One thing I have seen is a secondary federation executive style
progress
> > >that is sort of the game master. It handles initialization control so
> that
> > >order is not an issues and makes sure late joiners do not pick a bad
time
> >to
> > >spike the net...
> > >
> > >Bill Andrews
> > >
> > >----- Original Message -----
> > >From: ``Barclay, Nathan`` <[log in to unmask]>
> > >To: ``SISO - Run-Time Infrastructure and Communications Forum``
> > ><[log in to unmask]>
> > >Sent: Thursday, July 18, 2002 7:26 PM
> > >Subject: RE: Creating and Destroying Federations
> > >
> > >
> > > >
> > > > My understanding is that having every federate try to create the
> > >federation
> > > > before joining is merely a very popular convention - more or less a
de
> > >facto
> > > > standard, but not an official one.  It makes sure that no matter
what
> > > > federates are run (even federates originally designed for different
> > > > federations, if they`re compatible) or what order they are started
in,
> >the
> > > > federates can join.  But on the other hand, I can envision
situations
> > >where
> > > > a federation planner might want one particular federate always to
> start
> > >the
> > > > federation.  In such a case, making sure some other federate won`t
> start
> > >the
> > > > federation first by accident could be useful.
> > > >
> > > > Nathan A. Barclay
> > > > Teledyne Brown Engineering
> > > >
> > > > -----Original Message-----
> > > > From: Fay John F Contr AAC/WMG [mailto:[log in to unmask]]
> > > > Sent: Thursday, July 18, 2002 5:02 PM
> > > > To: SISO - Run-Time Infrastructure and Communications Forum
> > > > Subject: Creating and Destroying Federations
> > > >
> > > >
> > > > Ladies and Gentlemen,
> > > >         Somewhere I got the impression that the HLA specifications
> >require
> > > > that a federate try to create a federation before it joins it.  Now
I
> am
> > > > trying to find it in the HLA specifications and cannot.  Does
anybody
> >out
> > > > there know whether HLA actually requires this?
> > > >         I do find in the Interface Specification (page 15, second
> > >paragraph)
> > > > that the federation must exist before a federate can join it, but
this
> >is
> > > > different from saying that the federate must try to create it.  Any
> >light
> > > > that anybody could shed on this would be appreciated.
> > > > John F. Fay
> > > > [log in to unmask]
> > > > ``Et verbum caro factum est, et habitavit in nobis; et vidimus
gloriam
> > >eius.``
> >
> >Keith Snively
> >Dynamic Animation Systems
> >http://www.d-a-s.com
> >SAIC:(703)333-5432,
> >DAS:(703)503-0500
> >FAX:(703)425-2204
>
> Keith Snively
> Dynamic Animation Systems
> http://www.d-a-s.com
> SAIC:(703)333-5432,
> DAS:(703)503-0500
> FAX:(703)425-2204

--
----------
           \  / . .   /          Len Granowetter
            \/   _   (           MAK Technologies
                /-\   \          (617) 876-8085 Ext. 121
       T E C H N O L O G I E S      [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