Re: [certi-dev] startRegistrationForObjectClass Callback missing?

[Eric Noulard]

2011/9/16 Jan-Patrick Osterloh <address@hidden>:
> Dear all,
>
> we've got a question concerning the startRegistrationForObjectClass
> callback in CERTi when using HLA 1516-2000.
>
> First of all a Federate A must enableClassRelevanceAdvisorySwitch in
> order to get the callback startRegistrationForObjectClass. Then it must
> publish e.g. an ObjectClass X. If later on a Federate B joins the same
> federation as Federate A and subscribes to ObjectClass X then Federate A
> will get the callback  startRegistrationForObjectClass from RTI. This
> works fine with current CVS version of CERTi 1516.
>
> But what is if this two federates join the same federation the other way
> round? Federate B joins the federation and subscribes to ObjectClass X.
> Later on Federate A joins the federation and publishes ObjectClass X.
> Shouldn't get Federate A the callback startRegistrationForObjectClass in
> this context as well? The current CVS version of CERTi 1516 doesn't do
> so. In other words, the RTI doesn't "remember" that a Federate has
> subscribed to ObjectClass X when another federate publishes the already
> subscribed ObjectClass X later on.

I think it should.
At least that's how I understand 1516.1 document.

> Is the RTI intended to do so or is this simply a bug? In the bug tracker
> I found only a hint in bug #29453 to the callback but we think this on
> is obsolete as the callback is already implemented (at least partly).

It's a bug, but you see the task #6893 is unfinished,
https://savannah.nongnu.org/task/?6893
do you want to take over this task?

Whatever your decision,
you should file a new specific bug report in order to make it clear.

Currently NM_Start_Registration_For_Object_Class is only sent in
Federation::subscribeObject
and should be sent in
Federation::publishObject
as well.

as always patches are welcome.
I may not have time to do it myself but I may provide any informations you need
in order to implement this.

Slide 13 to 18 of
http://download.savannah.gnu.org/releases/certi/papers/CERTI-GenMsg-presentation-6june2011.pdf
should give you the big picture of the CERTI messaging system used for
building any
HLA service (or callback) with CERTI.


> Another question is about the implementation status of the callback
> turnUpdatesOnForObjectInstance which is normally activated with
> enableAttributeRelevanceAdvisroySwitch. We've seen that the switches are
> already implemented but due to this document
>
> http://cvs.savannah.gnu.org/viewvc/*checkout*/certi/doc/CERTI-HLA-ImplementationStatusList.ods?root=certi
>
> the turnUpdates* callback are still missing. Is there someone working on
> or is it possible to make a kind of feature request for that?

No one is currently working on this, and corresponds to the fact that Christian
who had worked on https://savannah.nongnu.org/task/?6893 did not get enough time
to make it through.

And yes you can file a feature request but in fact it's already the
purpose of task #6893
which essentially lacks ... [wo]manpower.

If you want to give it a shot, you may have a look at the companion test
for this feature:
http://cvs.savannah.gnu.org/viewvc/applications/HLA_TestsSuite/test_NotificationSwitches.cc?root=certi&view=markup
which is automatically tested using dtest script:
http://cvs.savannah.gnu.org/viewvc/applications/HLA_TestsSuite/dtest_test_NotificationSwitches.py?root=certi&view=markup

since you may not know dtest already you  may have look at:
http://download.savannah.gnu.org/releases/tsp/dtest/what_is_dtest.pdf
(and/or http://download.savannah.gnu.org/releases/tsp/dtest/dtest-0.5.1.tar.gz)

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org