Re: [certi-dev] Messages received after resignation

[Eric Noulard]

2015-04-08 16:39 GMT+02:00 Arnaud Degroote <address@hidden>:

On 08/Apr - 15:17, Eric Noulard wrote:
> 2015-04-08 14:05 GMT+02:00 Arnaud Degroote <address@hidden>
> :
>
> > Hi all,
> >
> > I'm not an expert in HLA, so I'm wondering if it a normal behaviour, or
> > an issue in the RTIG. I observe that I continue to receive some messages
> > from RTIG (in particular NM_Reflect_Attribute_Values) after I resign
> > from the federation. Is it normal ? Is there something I forget to do ?
> >
>
> No it's not.
>
> Which version of CERTI are you using ?

I use the last release version 3.4.3
>
> Would you be able to try with git master?

The issue is still here in master

OK then this is a bug :-)
 

> I would think that resign should generate "unsubscribe"
> but it is possible that no-one hit this scenario with CERTI before because
> one usually do
>
> create and/or join
> publish
> register
> subscribe
> ...
>
> unsubscribe
> unregister
> unpublish
> resign
> destroy

With a proper call of unsubscribeObjectClass, the message are not
emitted anymore.

Ok then the bug is still there. We should automagically unsubcribe when resigning.

Would you be kind enough to open a bug report for that?

Patch proposal are welcomed as well :-)

 

Why is the API not really symetric
(subscribeObjectClassAttributes vs unsubscribeObjectClass) ?

This is historical assymetry in HLA 1.3

both 

 unsubscribeObjectClassAttributes

and
unsubscribeObjectClass

exist in the 1516-2000 and 1516-2010 API.

see <ECRTI-SRC>/include/ieee1516-20*/RTI/RTIambassador.h

Moreover, I
would be more happy with an API to do the contrary of
requestObjectAttributeValueUpdate, but I don't find anything to do that.
Do I miss something ?

What to you mean by "the contrary" ?

One federate do

register+UAV (through RTIambassador)

and some others do

subscribe (through RTIambassador) and get RAV (through FederateAmbassador)

when you do

ROAV this is an explicit request to get extra value from the publisher even

if it did not do UAV on his own.

then the owner get PAVU = Provide Attribute Value Update

and the requester  should get back an RAV.

i.e.

UAV+RAV is a push mechanism between federate

whereas

ROAV+PAVU+RAV is a pull mechanism between federate

what other scheme are you thinking of?

>
> so that when resigning we did already unsubscribe.
>
>
>
>
>
>
> --
> Eric

> --
> CERTI-Devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/certi-devel


--
CERTI-Devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/certi-devel

--

Eric
L'élection n'est pas la démocratie -- http://www.le-message.org