bugCERTI - Bugs: bug #35719, Attributes published by no-one...

 
 

bug #35719: Attributes published by no-one will be requested by requestObjectAttributeValueUpdate()

Submitter:  Timi Tuohenmaa <timit>
Submitted:  Mon 05 Mar 2012 07:26:59 AM UTC
   
 
Category:  CERTI Severity:  * 4 - Important
Item Group:  HLA compliance error Status:  Fixed
Privacy:  Public Assigned to:  erk
Open/Closed:  Open Release:  * GIT-master
Reproducibility:  Every Time Fixed Release:  * GIT-master
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 07 Jul 2014 07:46:22 AM UTC, comment #4: 

I decided to look really good and actually offer a patch for this.

Patch is directly for 3.4.3 source. What I didn't change is the name of the function (requestObjectOwner) which is quite wrong (and it is not used anywhere for use it's name suggests).

Anyways, it did just check object owner and sent request for all attributes to that federate. That is not how it should work by HLA specs. I changed it to check owners by all attributes and to send requests for correct federates and also to request only those attributes that federate actually owns. This will also fix this bug ticket as unowned attributes are now ignored (as should).

I also fixed requestClassAttributeValueUpdate() as it had the same problem. It now uses requestObjectOwner() as it is actually same code that is needed.

(file #31683)

 Timi Tuohenmaa <timit>
Fri 04 Jul 2014 12:32:53 PM UTC, comment #3: 

I looked a bit for this issue. It seems requestObjectAttributeValueUpdate() will go to federate that is marked to be owner of the object. Owner seems to be called the federate that is owner of the privilegeToDelete attribute. There are some FIXME and BUG lines found relating this owner thing.

While one can say that the object owner is that object the request should not go to object owner but instead separately to owners of requested object attributes.

So this same issue is for attributes that are owned by different federate than "object owner".

I wonder if this object owner thing is even wider issue than only about update requests. Quick look seems to suggest that at least attribute ownership acquisition is done by attributes and not object ownership.

 Timi Tuohenmaa <timit>
Fri 27 Sep 2013 12:50:28 PM UTC, comment #2: 

Unfortunately I don't right now. It shouldn't be hard to reproduce though.

It happens when "federate 1" creates object and has certain attributes published. Then "federate 2" listens for such object but has subscribed to attributes that are only partially same as "federate 1" published. "Federate 1" will receive provideAttributeValueUpdate() when "federate 2" uses requestObjectAttributeValueUpdate() for these attributes as it should, but that provideAttributeValueUpdate() will contain also attributes that "federate 1" had never published.

It is probably irrelevant, but "federate 1" was creator of federation.

I later noticed that the same issue happens for attributes that were published by "federate 1", but were no longer owned by "federate 1".

I am not 100% sure anymore (sorry, it's been a while) if "federate 1" actually got requests for all attributes that were listed in fed-file for object no matter what attributes it had published or subscribed.

I think the relevant thing is that "federate 1" was the original creator of the object.

Timi Tuohenmaa <timit>
Fri 27 Sep 2013 07:51:09 AM UTC, comment #1: 

Hi Timi,


Do you have any ready-to  use source code example
that may help us to track down this issue?

 Eric NOULARD <erk>
Group administrator
Mon 05 Mar 2012 07:26:59 AM UTC, original submission:  

Attributes that no-one has published should completely ignored by requestObjectAttributeValueUpdate(), but instead they are now received at least in federate that owns the object in provideAttributeValueUpdate().

See: http://lists.nongnu.org/archive/html/certi-devel/2012-03/msg00001.html

 Timi Tuohenmaa <timit>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #31683:  UpdateRequestFix.patch added by timit (5KiB - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by timit (Submitted the item)

    •  

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-02 erk StatusNeed Info Fixed
        ReleaseCVS GIT-master
        Fixed ReleaseUnknown GIT-master
    2014-07-07 timit Attached File- Added UpdateRequestFix.patch, #31683
    2013-09-27 erk StatusNone Need Info
        Assigned toNone erk

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-5884.
    Corresponding source code