Re: [certi-dev] CERTI billard test / http_proxy

[Eric Noulard]

2009/5/20 Martin Spott <address@hidden>:
> Oh yeah, running RTIG on The Sun (32-bit binaries), two 'billard's on
> Linux AMD64 plus one 'billard' on The Sun works together nicely.
> This definitely makes a good start ! I'm just wondering why the setup
> fails to join yet another 'billard' into a system that's already
> executing. Whenever I try to join another one, it hangs at:
>
> foehn: ~> billard -fTest -FTest.fed -n X
> CERTI Billard 3.3.3cvs
> with TIMESTAMP. If you want without TIMESTAMP add -e option.
> BILLARD Note : FederationExecutionAlreadyExists Reason is : . OK I can join it
> Display(400, 265, 500, 100)
> Synchronization...
>
>
> ....  and the other ones stop moving. Is this just a special issue with
> the way how the 'billard' demo works or is it more of a 'feature' with
> CERTI in particular or even HLA in general ?

This is definitely not an HLA general feature.
Synchronization point in HLA gives the different "federate"
a way to coordinate themselves, up to a certain point.

Billard application was not mean't to make it possible for a billard
to join the federation/simulation AFTER others (may be only 1) did
pass the synchronization point.

Thus NO it's not an HLA "standard" behavior.
Yes it's the billard"fault", it should be more robust to "late federation join"
by either refusing to join handing the late join more peacefully.
This is definitely a billard bug, I think it should have worked in the past,
we'll look into it.
Bug filed:
  https://savannah.nongnu.org/bugs/index.php?26640

If you want to know more about HLA sync point keep reading,
if not just skip the rest of this message.

HLA "Federate" are the applications which are participating to the simulation
aka the HLA "Federation".

HLA Synchronization poinr are
some kind of rendez-vous which works the followinfg way:

1) call registerFederationSynchronizationPoint which request the RTI
     to handle the synchronization point. The SyncPoint may concern
     all the federation or a subset of it.

2) wait for the synchronizationPointRegistrationSucceeded callback
sent by the RTI
    this is the acknowledgment from the RTI that registration is done
    for this particular federate

3) wait for the announceSynchronizationPoint callback sent by the RTI
    this is the acknowledgment from the RTI. The callback
    is received  by each federate concerned by the SyncPoint
    (default is "every federate" unless otherwise specified in 1) ).

4) call synchronizationPointAchieved when he wants to notify that he
     has reached the "synchronized state".

5) wait for the federationSynchronized callback sent by the RTI
     which is the acknowledgement that all federate which
     participate to the SyncPoint have called "synchronizationPointAchieved".


Usually a "particular federate" participate to 1) and 2) and every federate
participate to 3), 4), 5).

In the billard example the first launched billard is the "creator" of
the federation,
the user is requested to "Press ENTER to start execution..." in order to
make the synchronization point possible. Because as you can see the mechanism
does need to convey the number of participant, thus  the "creator" billard will
make other wait by NOT sending "synchronizationPointAchieved" before
"ENTER" is pressed.

The second billard "blocks" the first one because of time synchronisation
which is unrelated to Synchronisation Point but. Like I said before
this is a billard bug, we should look into this.


-- 
Erk