[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[certi-dev] NextEventRequestAvailable and LBTS

From: Massimiliano D'Angelo
Subject: [certi-dev] NextEventRequestAvailable and LBTS
Date: Wed, 8 Aug 2012 18:02:09 +0200

Hi guys,
I am using CERTI and I have noticed an issue. 
I have two federates, say A and B, which are both regulating and constrained, with zero lookahead. I am using the NextEventRequestAvailable service. 
Let's suppose both federates are at time n and LBTS=n. Here is what happens:
1) Federate A performs a NextEventRequestAvailable(n+1)
2) Federate A receives a TSO at time n, and consequently the TimeAdvanceGrant to time n.
3) Federate B performs a NextEventRequestAvailable(n+1)
4) Federate B receives the TimeAdvanceGrant to time n+1. [IS THIS STRANGE?]
5) Federate A sends a TSO at time n
6) Federate B receives a TSO at time n, which is in the past with respect to its local time!!!
I would have expected at point 4 to have B blocked up to the point in which the grant can actually be given (Federate A requests again to advance its time to n+1) or a TSO arrives. 
Is this a bug in the protocol implementation or have I misunderstood the protocol behaviour?
Putting some printf in the RTIg, I noticed  that once Federate A requires to advance to n+1 (step 1), the RTIg stores n+1 as clock value of federate A, and uses this value to calculate the LBTS. At point 3, when the RTIG receives the request of federate B, the RTIg calculates the LBTS assuming that both federates are at n+1. So, it seems it does not properly take into account that the request to move to time n+1 by federate A has not been granted. 
FYI, I am using the NULL PRIME MESSAGE PROTOCOL (the simulation freezes using the default protocol).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]