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

 
 

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

Submitted by:  Timi Tuohenmaa <timit>
Submitted on:  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:  Eric NOULARD <erk>
Open/Closed:  Open Release:  GIT-master
Reproducibility:  Every Time Fixed Release:  GIT-master

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project AdministratorIn charge of this item.
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


    Powered by Savane 3.4