since yesterday new dtest script is in cvs
dtest_test_NotificationSwitches

Hi Eric,

I try to implement a dtest script at the weekend. Hope that this is fast enough.

>>Since some of switches are now implemented would you
>>be possible for you to either:

In my opinion the switches are already implemented. You can set a flag within a federate by using the appropriate methods below:

enableClassRelevanceAdvisorySwitch(),
disableClassRelevanceAdvisorySwitch

enableInteractionRelevanceAdvisorySwitch(),
disableInteractionRelevanceAdvisorySwitch

enableAttributeRelevanceAdvisroySwitch(),
disableAttributeRelevanceAdvisorySwitch()

enableAttributeScopeAdvisorySwitch(),
disableAttributeScopeAdvisorySwitch()

What is left are the required callbacks. Only startRegistrationForObjectClass works at time.

Bye

Just committed.

Next week I proceed with stopRegistrationForObjectClass .

Happy Easter!

Christian

Hi Eric,

how to proceed? Can I check in the patch?

forgot the new patch.

(file #17856)

Christian,

I've just merged-in a long-standing relatively big patch
which was made by Petr in order to restore a clean
windows build.

see
https://savannah.nongnu.org/bugs/?24930

Your latest Notif patch may be applied to the new
HEAD without trouble, however I urge you to
update your tree before having conflict.

Thanks for your investigation.

This is indeed the problem.

For a fast test I did the following within
RTIA/ObjectManagement::discoverObject

...
 try {
    rootObject->registerObjectInstance(fm->federate, the_class,    the_object,
    req.getName().c_str());
 }
 catch (ObjectAlreadyRegistered) {
 }
...

Now the assert do not occur. So obviously you find the problem.
Thanks again.

The problem here is that the first discoverObject callback in the test_Notification federate registers also the object instance.

After the resubscription the second discoverObject callback try to register an already registerd object class.

We have some possibilities to handle the situation:

1) catch exception like shown above

2) each unsubscribe deletes all registered object instances of the object class

What do you think is a good solution for this case?



 

Hello Petr, hello Eric,

thanks for your information.

When you apply my last patch attached at the tracker, the error occurs if you uncomment both commented lines within the subscriber part of current test_NotificationServices federate in the HLA_Testssuite folder and then compile and execute the test_Notification federate (see my last post).

The creator (publisher) of the federation publishes an object class. Next, the creator registers an object instance.

The second federate subscribes to that object class and you will hopefully see that the creator get the callback startRegForObjClass (thanks to the patch). The subscriber should get the callback discoverObjInst.

Everything seems to work, but now the subscriber unsubscribes the object class. After that, the subscriber re-subscribes to the object class.

the creator (publisher) should get again the callback startRegForObjClass (works for me). The subscriber should get the callback discoverObjInst (works also for me).

But at the same time I get that error also described by Eric:

> The trouble here is that the RTIA end up in execute with a
> tm->_tick_state == TICK_NEXT

Additionally, if you never register an object within the creator you can subscribe and unsubscribe to an object class as ever you want. All works as expected, the creator will get its callback startRegForObjClass after every resubscription.

So, my first suggestions aimed to the recursive discovering process invoked within ObjectClassSet::subscribe.

But perhaps I've only made a implementation fault.

At time I do not know the reason.

I'm not sure where to start the troubleshooting. My first idea was to ask the CERTI community. Perhaps anyone knows immediatly how to solve that problem.

I add some explanations about the CERTI subscription process as I understood it into the patch as code comments.

I'm also not sure if I understand the post of petr correctly:

> It's a transient state indicating a tick() callback has been
> processed, but tick() hasn't completed yet.

What do you mean with "tick() hasn't completed yet".

I did your patch a try.
The good thing is that the current patch does not
break current test (automated part of HLA_TestSuite and billard)
however when I do uncomment the offending
re-subscription in the federate I do get RTIA assert error too:

The trouble here is that the RTIA end up in execute
with a
tm->_tick_state == TICK_NEXT
which is not expected here.

I do not manage [yet] to understand either

1) why it is not allowed to be in this state?
2) what lead the time management to this state?

I add Pierre and Petr as cc because they master TimeManagement
tick state handling, may be they can help us with this.

Hi Eric,

hope you had a successful conference talk.

I added again a small patch. Now, the callback startRegistrationForObjectClass is forwarded to the federate.

Please review the patch, so I can advance my work. Also I added some comments regarding future and current implementation details. Perhaps we can talk about it.

I tested with all existing dtest scripts and billard. Everything seems to work.

I also checked in a new version of the test_Notifcation federate.

Everything works, the callback startRegForObjIns is forwarded to the publisher of the objectClass. BUT: You will see that I uncomment two lines in the subscriber part of the test federate.

These two lines realize a resubscription. Since the creator of the federation publishes and registers an object the subscriber should rediscover the object after resubscription.
When the code is executed, the subscriber terminates with an error message. I put the error message as comment in the test federate code (subscriber part) too. The error says: "RTIA.cc:170: void certi::rtia::RTIA::execute(): Assertion `false' failed."

At time I can not say what are the reasons for that behaviour. Perhaps you or anyone else can help.

(file #17819)

Okay again a patch hopefully compatible with your
advices.

If you have no further remarks I'd like to check-in that
small patch.

In my opinion we should iterate relativly often through
the code changes. So we can discuss the changes in more detail
(only for the first time implementing notification services)

Later I would provide bigger patches.






(file #17072)

Hello Eric,

I've attached a small patch.

That patch is for reviewing only. It implements a
possibility how information for the current publishers
of an object class can be retrieved.

I'd like to know your opinion about that implementation.

If you like that approach I would resume my work and implement
the final callback startRegForObjClass hopefully at the end of
this week (then also with doxygen comments).



(file #17069)

The following notes are concerned to the implementation
of start- and stopRegistrationObjectClass Federate Services.

This are mainly personal notes and can be regarded as implementation proposal:

In
ObjectClassSet::subscribe
- call recursiveNotification method
- recursiceNotification method -> implementation in ObjectClass.cc

In ObjectClass::subscribe
- test if attribute are already published, return boolean (probably by reference)
- required methods ObjectClass:.isFederatePublisher or/and
ObjectClassAttribtue::isPublishing

Hmmm, I'm confused. I do not know and not have such a GUI
for UNIX-like systems. I know that only from Windows.

So where to set the global options within a file. I always
thoughtthat I have to do it with the toplevel CMakeLists.txt file.
There is an option BUILD_DOC which I can switch to on.

But this seems not enough, only the user and the install docs
are generated by default.

That's why I changed doc/CMakeLists.txt I set the Build devel
option to on.

Perhaps I do not known where to set global options?

And another question is concerned to the so-named "DOT tools"
My cmake run in a build dir says that it cannot find the
dot tools.

Okay, find the solution.

Have to edit doc/CMakeLists.txt within the source dir
and set dev docs to on.

Hi Christian,

Your comment are fine and I think that if everyone
does this "no so little" effort each time we implement
or update and API we will have a much greater source code
understanding and quality.

I have 2 small remarks:
 
  1) It's usually better to put function documentation
     in the header file (.hh) that in the body file (.cc)
     since such documentation should be seen as a specification
     for the API.
     Moreover when API is public (i.e. whe .hh is exported)
     the user may have a look at the header file in order
     to find valuable information.
     He may not find it in .cc since he may not have it.

     Implementation detail may/should be put in .cc
     In this case they cannot be attached to an API but
     your may create a @defgroup Whatever .
    

  2) You may usually remove "This method", because
     we already know that the comment concerns the following
     method (this will be explicit in Doxygen generated
     doc too).

     You may ommit @return when void.
     It may be interesting to add the intent of the parameter
     using @param[in], @param[out] or @param[in,out]

     You don't have to specify the type of the param because
     it's already part of the API unless you give a more
     precise information, i.e. int considered as boolean or
     enum value etc...

    For example (from RTIG/Federate.hh)
    /**
     * This method sets the ClassRelevanceAdvisorySwitch of the federate
     * to the value of the input parameter val. The CRA switch is enabled
     * by default.
     * @param val is a boolean [true, false]
     * @return void
     */
     void setClassRelevanceAdvisorySwitch(bool val) { cras = val ; };

    May become:
     /**
     * Sets the ClassRelevanceAdvisorySwitch of the federate
     * to the value of the input parameter val. The CRA switch is enabled
     * by default.
     * @param[in] val new value for the switch true means enable
     *            false means disable.
     * @return void
     */ 
    
Those remarks are just "advices" you may commit as-is.
I should have sent recommandation for doxygen comment on
certi ML, I'll do it soon.

Concerning the switches semantic I do not have time
to look at it deeply for now.
I suggest we do it iteratively beginning with your
understanding.

I know Patrice is using the feature with other TI
may be he can explain us his understanding of the service.

Hi Eric,

I just checked in.

Tomorrow I will add some doxygen comments.

Next week (hopefully) the second part will follow.

Then we have to implement the required callbacks and
the logic in combination with the switches.

Okay, now I tested the patch with the test_Notification federate from the HLA_Testssuite folder. I've seen that I've forgotten the replies from RTIG back to RTIA. That's why again a new and now hopefully working patch.



(file #16884)

Sorry, I've just reviewed my own patch and find some mistakes. The defualt initialization for the switches ara and asa are false, not true.

That's why only the last patch is the correct one.

(file #16882)

I attached a first major patch. It implements the
switches CRA, IRA, ARA and ASA.

Map is probably not the correct term, perhaps array
or matrix fits better. Have a look at the tables in
chapter 5 (l'heritage ...).

>>You should know that most of the subscriber/publisher
>>informations are currently stored in the
>>Federation::RootObject
>>...
>>What I want to point out is that before adding
>>more information into Federate.cc/.hh have a look
>>at the RootObject hierarchy of informations since
>>you have the hand on it in Federation.hh.

Thanks for your hints. But what I've meant is concerned
to switches. For example we have the routines
enableClassRelevanceAdvisorySwitch(), enabled by default and
disableClassRelevanceAdvisorySwitch.
 
So, the question is, where to store that flag/switch.
If it is stored in RTIA, we have to transfer a startRegistrationForObjectClass message for each
subscription form RTIG to the RTIA of the publisher(s)
of the object
class attributes. That is the same for all other notification
services. Then we can decide within RTIA if we transfer
the callback up to the federate depending on the switch status.

If we implement the switch information within RTIG only the
necessary message transfer is needed. I think that this is
more performant. So where to implement that information on the
RTIG side? My proposal was to use RTIG/Federate.hh/cc because
there are also the constrained and regulating flags stored.

Don't hurry. I will be back tomorrow.

Hello,

I've just started. First I try to implement start/stop
RegistrationForObjectClass (RFOC)

What do you think of the idea to expand the information
holded in RTIG/Federate.cc . Here we can hold switches and so on.

The subscribeObject routine in RTIG/Federation.cc can iterate
through all federates and initiate all required callbacks (RFOC)
on basis of the information hold in RTIG/Federate.cc.

On that level we can collect all required information.

Another question: Do you know where I find that map referred
in the rapport du stage you've send me? In chapter 5 the
principle implementation is explained. I suggest that useful
information can be found within step 2 (debut) and step 3 (diffuser).

Hi Eric,

do you already work on that topic? I've reviewed your last cvs
checkins and I've oticed that you work on Interaction and
objects.

> sorry that I have to disappoint you.

No you don't :=)

> But in the last weeks I mainly worked at a
> publication in English, that consumed all my time.

Good to ear that, PhD student must publish their work.

> Before the mid-September I really cannot resume my
> implementations.

I understand taht too, I will come back to you
when we have a CERTI library which fullfills your need.

> Here we need an easy interface/data structure to get all
> federates which subscribed and/or publicated interaction classes
> and their parameters and attribute classes and their
> attribute values respectively. Thereby, it must be dealed
> with care attention of inheritance relationship.

OK I see. We (may be I)  should do that work.
We do not have such interface currently because
the broadcast/multicast mechanism used to send
messages to subscriber is done in another way.

I'll try to send you a report about the algorithm
used, however I think it is written in french.

Do you read french?
(We need more english documentation anyway but it
 may be faster to forward you the current french report)

And don't worry, about "pausing" CERTI devel,
we all know that Open Source development goes that way
unless some of us get paid for doing OSS dev :=)

Hi Christian,

How does your work on notif goes?
I'll try make a CERTI 3.3.1 bug fixe only release
in a week or two then I'll be happy to try to merge your
work as soon as your are ready.

I'm not pushing you, I just coming for news after
long holidays  :=)

Hi Christian,

I've created a  "br_DEV_NotifServices" branch.
You may use it and commit inside the branch.
The tag exists for both "certi" and "HLA_TestsSuite"
modules.

In order to use the branch you should either relocate
you current tree to the branch using:

cd /path/to/certi
cvs update -r br_DEV_NotifServices
this may generate merges depending on the up to date
state of your tree.

or more simply get a fresh checkout of the branch:

cvs -d:ext:approx@cvs.savannah.nongnu.org:/sources/certi co -r br_DEV_NotifServices -d certi_Notif certi

(-d certi_Notif option of checkout do the checkout
 in a directory whose name in certi_Notif)

In order to check whether if you are in the "branch" version
you may use cvs stat on a file:

certi_Notif$ cvs stat README
===================================================================
File: README            Status: Up-to-date

   Working revision:    3.1
   Repository revision: 3.1     /sources/certi/certi/README,v
   Commit Identifier:   (none)
   Sticky Tag:          br_DEV_NotifServices (branch: 3.1.8)
   Sticky Date:         (none)
   Sticky Options:      (none)
certi_Notif$

as you can see the file now has a "sticky" tag of the branch.
Once you are on the branch, your commit will go to the branch.

If you want to report uncommited changes from your current
CVS tree to the new checked-out tree (in the case you did
a fresh checkout) then you may create a patch from the
first tree, and apply the patch to the new tree.

1) cd /path/to/certi
   cvs diff -u  > /tmp/tobereported.patch

2) cd /path/to/certi_Notif
   patch -p0 < /tmp/tobereported.patch

should work.

I'm on holiday on thursday so may be you can try to use the branch in the meantime such that we can fix eventual trouble
before thursday.

Hi Christian,

I agree with you we need a clean and complete
set of association between class hierarchy (aka ObjectClassRoot)
publishers and subscribers.

However currently the "inheritance" property with
respect to subscriber (and UAV/RAV) is handled through
a kind of recursive algorithms which will ensure
that subscribers to a leaf class are informed
of an UAV on attribute on higher (in the class hierarchy)
class.
(I'm not sure to be clear here).

I will be lacking time before I go on holiday next week
so I'll propose you prepare an appropriate patch
for your usage, and we will merge it together after
10th of august.

Is this timescale OK for you ?

If you need intermediate commit, I may create a
development branch for you such that you may commit
as you like and we will merge all or part of it
in august.

Christian,

I must say that I do not know this area of the code very much :=(
I'll have to analyze it before being able to answer.

Moreover I will be on holiday on 16th of July and
away from keyboard for a while.

Pierre has gone on holiday today :=(

However after a first look I would say that making
"ObjectClass::isPublisher" may be a good solution.
The thing I don't like very much is the complexity
of the resulting algorithm since
ObjectClass::isPublisher iterate over all attributes
of the class ask the attribute itself if the federate
publish it...

list<ObjectClassAttribute *>::const_iterator a ;
    for (a = attributeSet.begin(); a != attributeSet.end(); a++) {
        if ((*a)->isPublishing(the_federate))
            return true ;
    }

ObjectClassAttribute::isPublishing call STL find algorithm.
Thus you end up with 3 nested search loop (your loop + 2)
which should be very slow if one have a lot of ObjectClass
and a lot of Attribute per class...

I think that if we have to do such search this means
we should build another "map/list/..." during publish
which gives more direct access to what you need

"the list of federate publishing an attribute of the
 current object class"

one may easily build this list during publish.

I need more thought and I'm not sure to be able to
get it before holidays...

To your last comment: You shouldn't blame yourself let's
say this was an effect called Murphys Law :).

But now I suppose I need some help. LibCerti and
especially the ObjectClass hierarchy is not so easy to understand.

My aim was the following:

I want to send a callback startRegistrationForObjectClass as fast
as possible to the publishing Federates.
So I figured out
RTIG/Federation::subscribeObject (FederateHandle federate,
              ObjectClassHandle object,
              std::vector <AttributeHandle> &attributes,
              UShort list_size)

as my entry method.

Here I like to do the following:

  // cycle through all federates and test if it is an
  // publisher of the ObjectClass with the handle object

  for (FederateList::iterator j = federates.begin();
       j != federates.end(); ++j) {
        ObjectClass* test = root->getObjectClass(object);
       if (test->isFederatePublisher(j->getHandle()) {
          // execute cb startRegForObjClass
       }
  }

My problems are:
isFederatePublisher is a private method of the class ObjectClass.
So it can not be accessed in that way. Can or should I make that
method public?

Is that approach a good one? Are there better approches, perhaps
on a different level. For example the callback can be executed
somewhere in the ObjectClass* classes.

Are there already methods telling me which object classes a
federate currently publishes or subsribes.

Hi Christian,

2 remarks:

  - you have some spurious copy/paste comment
    in NM_Classes.hh concerning the new msg
 
  - when you add a message you'd rather extend
    the enumeration at the end because if you insert
    a value "in the middle" as you did
    a mismatch in RTIA/RTIG version
    (if a user runs an older RTIG against a new RTIA+Federate)
    will generate a bug that would be harder to track
    [in fact we should add a version check initial message
     in RTIA constructor but in the meantime...]

Try to make this 2 small changes and commit your changes.
I'm OK with this.

I've see that Eric assigned the related bug to this task.

As I've already described below I want to start within
Declaration Management and the switch Class Relevance Advisory Switch.

It is enabled by default. To disable the switch we need
the method disableClassRelevanceAdvisorySwitch. To re-enable
the switch the method enableClassRelevanceAdvisroySwitch is
required.

A publisher of an object class gets the callback
startRegistrationForObjectClass if there are any new subscribers
(if CRA switch is enabled)

If there are no more subscribers a publisher gets the callback
stopRegistrationForObjectClass (if CRA switch is enabled).

I will put a first test federate (test_NotificationServices)
in the HLA-Testsuite folder.
I'd like the approach announced by Eric only to have one
file for the special test cases for the whole federation
(like parallel programming :)). This test federate will grow
with the implementation status of this task.

Your patch seems OK to.
It does not seem to exhibit regression
since billard, tutorial and HLA_TestSuite runs OK.
I have just applied it to the current CVS.
however next time you may apply the patch yourself
just after review.

I have a question, how will you test those new
services?

Hello Eric,

here's a first small patch preparing RTIA for further
refinements.

Please have a look and if you like apply the patch.

I want to save my work.

(file #16084)

Thanks Eric.
I've obviously forgotten the switch
Attribute Scope Advisory Switch 
+ methods
enableAttributeScopeAdvisorySwitch(),
disableAttributeScopeAdvisorySwitch()
+ callbacks
attributesInScope(),
attributesOutOfScope()

Hi,

this task a bit more complex. So I describe the necessary
"to-do" steps:

At first we need some more switches and enable/disable methods:

This are:
enableClassRelevanceAdvisorySwitch(), enabled by default
disableClassRelevanceAdvisorySwitch

enableInteractionRelevanceAdvisorySwitch(), enabled by default
disableInteractionRelevanceAdvisorySwitch

and

enableAttributeRelevanceAdvisroySwitch(), disabled by default
disableAttributeRelevanceAdvisorySwitch().

The ECRA switch is used to notify a federate in changes of
object-class registration relevance.

If the ECRA switch is set, the publisher of an object class gets the callback
startRegistrationForObjectClass()
if there is a subscribtion of another federate. The callback
stopRegistrationForObjectClass()
is invoked when there are no more active subscribers.

The EIRA switch is used to notify a federate of changes in the
interaction-class relevance.

If the EIRA switch is set, the publisher is informed through the
callback
turnInteractionsOn()
when tehre are active subscribers. If there
are no active subscribers the callback
turnInteractionsOff()
is invoked.

The EARA switch is used to inform the publisher of changes in
attribute-instance update relevance.
Same as above for attributes. The callbacks are
turnUpdatesOnForObjectInstance()
turnUpdatesOffForObjectInstance()

Hope that I get all points. My plan is to create several patches.
The first patch will add ECRA switch with the enable/disable methods plus the callbacks startRegistrationForObjectClass and
stopregistrationForObjectClass.
The second patch will deal with EIRA and corresponding methods and callbacks, the last patch with EARA ... .

This is my roadmap. The work will start soon ... .

Hello Eric,

I will start with this task in aprox. 2 weeks. AT time we prepare
a booth for the Automatica in Munich (a robot application) so
I've no further time for programming additional stuff.

Perhaps after that, we can talk again about the "message
refactoring".


So long,
Christian

Or perhaps better, we should implement a general
message class. NetwokMessages and RTIA<->Federate Messages
will than be inherited.

A first proposal ;)

Go ahead Christian,
However I have 2 recommandations:

1) I did commit some change to NetworkMessage
   in order to make more field private
   in order to enforce getter/setter usage
   Most notably for:
        - date
        - tag
        - label

   Please update before beginning your work.

2) As a general concern if you encounter
   portion of the code that you think needs
   more "global" rework beside the current feature
   under development do not hesitate to submit
   your opinion.
 
   Current part which needs work are:
       - Replace PrettyDebug with a clean
         logger interface (I may be doing this)
       - Uniformize exception handling
         (JYR has begun this task)
       - Make Message (RTIA<->Federate) class
         more "object-oriented" and throw
         up most switches. Just like we did with
         NetworkMessage


  What I mean is not to begin global rework while
  implementing a feature but think about it and
  submit your idea.
 
  CERTI code base is old and some part of the code
  NEED rework/redesign we know it.
  When we have clear idea and time to do it we will
  do the job.

I'll discuss more about this on the ML.

The service should signal a federate that he needs
to declare its (already published) object instance
or send interaction since another federate did
subscribe to the corresponding service.

Concerned API:
startRegistrationForObjectClass
stopRegistrationForObjectClass
turnInteractionsOn
turnInteractionsOff