Re: [certi-dev] Messages received after resignation

[Arnaud Degroote]

On 08/Apr - 17:04, Eric Noulard wrote:
> 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?

Will open an issue
> 
> Patch proposal are welcomed as well :-)

I will take a look in my spare spare time, so I don't guarantee anything
:).
> 
> 
> 
> > 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?
> 
Nothing, it was an misunderstand on my side, I thought that ROAV is
needed to get update in addition to subscribe. Now, your previous
comment makes sense.
> 
> 
> > >
> > > 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

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

signature.asc
Description: Digital signature