bugCERTI - Bugs: bug #32503, federate callbacks are invoked...

 
 

bug #32503: federate callbacks are invoked with incorrect timestamp value

Submitted by:  Eugene Chemeritskiy <tyz>
Submitted on:  Wed 16 Feb 2011 10:00:46 AM UTC  
 
Category: CERTISeverity: 3 - Normal
Item Group: Software errorStatus: Ready For Test
Privacy: PublicAssigned to: Eric NOULARD <erk>
Open/Closed: ClosedRelease: 3.4.0
Reproducibility: NoneFixed Release: 3.4.1

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Fri 18 Feb 2011 11:29:36 AM UTC, comment #8:

Ok fine.
Just commited to CVS HEAD.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 18 Feb 2011 10:39:36 AM UTC, comment #7:

Eric,

Thank you for your patch. It works fine.
Actually attached federates refused to work immediately after the patch was applied. But it is not your fault and it was not difficult to made them work properly.

Eugene Chemeritskiy <tyz>
Project Member
Thu 17 Feb 2011 04:05:24 PM UTC, comment #6:

Eugene,

Some more explanation about my proposal.
Theoretically your patch was the right one.
Now current CERTI implementation does (for UAV):

see in RTI1516ambassador.cpp:

certi::FederationTime certiFedTime(certi_cast<RTI1516fedTime>()(theTime).getFedTime());
req.setDate(certiFedTime);

so basically we assume that "theTime" is a CERTI "RTI1516fedTime"
and cast it out such that the value included in the message
is a CERTI FedTime...

We should have encoded the user provided value as an opaque type
and make it flow through CERTI until it comes out on
receiver side.

We had good reason (in the past) to do that, but this is a long story.
The consequence is that CERTI won't work as-is with user provided
LogicalTime...

Until now nobody screamed about that because no-one tried to
use its own time class :-]

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 17 Feb 2011 03:54:31 PM UTC, comment #5:

Ok now I see,

Off course we must give the federate appropriate value.

I'm afraid that won't currently work.
The value you get from the message is not
a user encoded time value :-(

This is an internal certi value,
is your patch working as expected on your side?

I think it should be more something like:

std::auto_ptr < rti1516::LogicalTime > fedTime (new RTI1516fedTime(msg->getDate().getTime()));

I'll attach my patch proposal right after that.
It seems to work with your example.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 16 Feb 2011 02:45:51 PM UTC, comment #4:

Hi Eric,

Thank you for fast reply.

>> However I do not quite understand:
>> "But federate ambassador callbacks are still invoked with initial timestamp parameter value"


I mean that RTI should somehow assign a corresponding timestamp value to parameter before passing it to federate (now it just passes initial value of required type).

>>When you propose modification would you be able
>>to do it as a "patch file" (a diff file) ?


Okay, I'll try to attach patch & diff files as well as my test federation.

Now I see that proposed fix has has the same endian problem but may be you can fix it with another encode implementation also.

(file #22700, file #22701, file #22702)

Eugene Chemeritskiy <tyz>
Project Member
Wed 16 Feb 2011 12:39:12 PM UTC, comment #3:

I've just checked in CVS HEAD the modified
RTI1516fedTime.cpp.

encode/decode using "rti1516::VariableLengthData" should work.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 16 Feb 2011 11:56:50 AM UTC, comment #2:

Hi Eugene,

Thank you for your report.
I'll try to handle it with your help.

Your proposal for encoding/decoding is not complete
we should take care of endianity because those time value
may be sent accross the network between 2 hosts with different
endianity.

This is not that complicated to implement
we can mimic what is done in
RTI1516fedTime::encode(void* buffer, unsigned long bufferSize).

I'll try to do that myself (include the RTI1516TimeInterval class).

Concerning 1516 compliance you are right.
However I do not quite understand:

"But federate ambassador callbacks are still invoked with initial timestamp parameter value"

When you propose modification would you be able
to do it as a "patch file" (a diff file) ?

It is far easier to review/test.

Moreover if you have a federate test case please attach it
to the tracker too. We may use it to reproduce the error
and may b add it to our non-regression tests suite.

I'll post another comment when I've done the encoding part.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 16 Feb 2011 10:11:05 AM UTC, comment #1:

Also RTI1516fedTime class implementation should be refined.
There are several stubs on encode & decode functions.

RTI1516fedTime.cpp:216:

rti1516::VariableLengthData
RTI1516fedTime::encode() const
{
// old source code
//throw std::wstring(L"rti1516::VariableLengthData not supported");
// proposed fix
return rti1516::VariableLengthData( &_fedTime,sizeof( _fedTime ) );
}

RTI1516fedTime.cpp:315:

void
RTI1516fedTime::decode(rti1516::VariableLengthData const &encodedLogicalTime )
throw (rti1516::InternalError,
rti1516::CouldNotDecode)
{
// old code
//#if defined(_WIN32) && defined(_MSC_VER)
//throw std::wstring(L"rti1516::VariableLengthData not supported");
//#else
// //throw rti1516::CouldNotDecode(L"rti1516::VariableLengthData not supported");
//#endif
// proposed fix
_fedTime = (double)encodedLogicalTime.data();
}

The similar corrections should be implemented to RTI1516TimeInterval class.

Eugene Chemeritskiy <tyz>
Project Member
Wed 16 Feb 2011 10:00:46 AM UTC, original submission:

It seems to me that current CERTI release is not fully compliant with HLA 1516 in the domain of custom time management classes: there exists hardcoded internal implementation of them.

Nevertheless this approach combined with RTI1516fedTime & RTI1516fedTimeInterval classes provide abilities to use RTI services. Moreover passing instances of such classes to RTI currently are handled correctly.

RTI1516ambassador.cpp:504
certi::FederationTime certiFedTime(certi_cast<RTI1516fedTime>()(theTime).getFedTime());

But federate ambassador callbacks are still invoked with initial timestamp parameter value. I think that using of described approach should be logically finished and callback implementation should be refined.

There are several samelike code rows in RTI1516ambPrivateRefs.cpp
that should be corrected:

std::auto_ptr <rti1516::LogicalTime> fedTime = getLogicalTime();
----------------------------------------
// proposed fix starts
double t = msg->getDate().getTime();
fedTime->decode( rti1516::VariableLengthData(&t,sizeof(t)) );
// fix ends
----------------------------------------
fed_amb->removeObjectInstance( instance, ...

Eugene Chemeritskiy <tyz>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #22716:  bug32503-erk1.patch added by erk (3KiB - text/x-diff - Another patch proposal)
file #22700:  test_fed.tar.gz added by tyz (9KiB - application/x-gzip)
file #22701:  diff added by tyz (3KiB - application/octet-stream)
file #22702:  RTI1516ambPrivateRefs.cpp added by tyz (41KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 13 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 18 Oct 2011 08:40:11 PM UTCerkOpen/ClosedOpen=>Closed
      Fixed ReleaseCVS=>3.4.1
    Fri 18 Feb 2011 12:24:30 PM UTCerkStatusNeed Info=>Ready For Test
      Fixed ReleaseUnknown=>CVS
    Thu 17 Feb 2011 03:56:09 PM UTCerkAttached File-=>Added bug32503-erk1.patch, #22716
    Thu 17 Feb 2011 03:54:31 PM UTCerkStatusIn Progress=>Need Info
    Wed 16 Feb 2011 02:45:51 PM UTCtyzAttached File-=>Added test_fed.tar.gz, #22700
      Attached File-=>Added diff, #22701
      Attached File-=>Added RTI1516ambPrivateRefs.cpp, #22702
    Wed 16 Feb 2011 02:45:11 PM UTCtyzCarbon-CopyRemoved tyz=>-
    Wed 16 Feb 2011 11:56:50 AM UTCerkStatusNone=>In Progress
      Assigned toNone=>erk
    Wed 16 Feb 2011 10:00:46 AM UTCtyzCarbon-Copy-=>Added tyz

    Back to the top


    Powered by Savane 3.1-cleanup1