[certi-dev] Bug report

[Yaomin Fu]

Eric,

It has been a long time I haven't touch the CERTI stuff, but find a  
note of a bug worked out previously. I am not sure whether it is  
submitted and have forget my password to access the CERTI development  
page. So pass it to you here:

Buggy behavour:
A federate that does not publish and only subscribes receives  
incorrect object class handle as a result of querying rti by object  
handle if it joins the federation execution after other federates.

Expected behavour:
As a result of invoking rti ambassador service  
getObjectClass(ObjectHandle), the returned value is a handle of a  
class of which the object is. The class should be at the same level of  
the object in the class hierarchy tree, not the super class of the  
object.

Cause:
RTIA rootObject->Objects has a std::map contains (object handle,  
object*) pairs for published objects.
The map is populated as a consequence of message process of either  
register object instance or subscribe object class.
In the situation described above only the later occurs and the map is  
populated incorrectly.

The method call chain of message process:

RTIA sends NetworkMessage::SUBSCRIBE_OBJECT_CLASS message to RTIG
RTIG to process NetworkMessage::SUBSCRIBE_OBJECT_CLASS message:
RTIG::processSubscribeObjectClass()->FederationsList::subscribeObject()->Federation::subscribeObject()->ObjectClassSet::subscribe()->ObjectClass::subscribe()
If the last method returns as it is a new federate, the caller will  
invoke a discover process to send NM_Discover_Object messages to RTIA  
for all published objects of the subscribed class, as well as those of  
all its sub classes.
ObjectClassSet::subscribe()->ObjectClass::recursiveDiscovering()->ObjectClass::sendDiscoverMessages()
In the sent out message, the handle of the subscribed object class is  
then assigned to the objects of the subscribed class and also those of  
the sub class.
In other word, an object may be assigned with multiple handles of its  
super classes.

RTIA to process DISCOVER_OBJECT message:
TimeManagement::executeFederateService()->ObjectManagement::discoverObject()->RootObject::registerObjectInstance()->ObjectSet::registerObjectInstance()
The last method stores a (object handle, object*) pair in the object  
map in rootObject->Objects container.
If a DISCOVER_OBJECT mesaage with (object handle, super class handle)  
comes first, the object->class is set to the super class handle, and  
prevent the correct one coming late from being stored.
Then if RTIA is queried for class handle by object handle, incorrect  
answer is returned.

Fixing:
change one line of code in ObjectClass::sendDiscoverMessages() to  
associate correct class handle to the object,
        message.objectClass = (*o)->getClass();




Note:
NetworkMessage DISCOVER_OBJECT only from RTIG to RTIA

Upon receiving REGISTER_OBJECT_INSTANCE message from federate, RTIA  
sends NetworkMessage::REGISTER_OBJECT message to RTIG
RTIG to process NetworkMessage::REGISTER_OBJECT message:
RTIG::chooseProcessingMethod()->RTIG::processRegisterObject()->FederationsList::registerObject()->Federation::registerObject()->RootObject::registerObjectInstance()->ObjectSet::registerObjectInstance()
Stores (object handle, class handle) correctly
If succeeded, RTIA receives REGISTER_OBJECT back from RTIG and stores  
(object handle, class handle) pair:
ObjectManagement::registerObject()->RootObject::registerObjectInstance()->ObjectSet::registerObjectInstance()

DISCOVER_OBJECT is also processed in:
ObjectClassSet::registerObjectInstance()->ObjectClass::registerObjectInstance()

RTIG to process UPDATE_ATTRIBUTE_VALUES message
RTIG::chooseProcessingMethod()->RTIG::processUpdateAttributeValues()->FederationsList::updateAttribute()->Federation::updateAttributeValues()->ObjectClassSet::updateAttributeValues()

Best,

Yaomin