Re: [certi-dev] TAG and transient message

[David Come]

Hi.

Any update on that ?

Thanks,
David.
Le 01/07/2015 06:50, Pierre Siron a écrit :

Hello David,
I have reproduced this behaviour with the interactive federate
(just s/uav/si/).

A             RTI             B
                   NER(100)

               <--------------
    SI(1)
-------------->
    NER (100)
-------------->
                   RI(1)
               --------------->
                   TAG(1)
               --------------->
                   NER(100)
               <---------------
                   TAG(100)
               --------------->

I suppose that this is ok until the last TAG(100).

With the NER(100) of the federate A,
there is a NULL MESSAGE PRIME sent with 100.
This NULL MESSAGE PRIME shoud accelerate the time advancement
of B one time, not many times.
This looks like a lack of variable reinitialization
and I (we) have to review the CERTI code here.

A bientôt,
Pierre

Le 30/06/2015 21:05, David Come a écrit :

Hello.

Please find attached two quick and dirty C++ applications that reproduce the same behaviour.
They are a direct rip off of the Interactive_federate from the application folder. The only important parts are the PubSub, send methods and the mains' loops.

I put a schema describing the simulation architecture.

Bulding and using :
unzip source.zip
mkdir bin
cd bin
cmake ../src
make
./A_loop Federate_Name Absolute_Path_To_Fed_file
./B_loop Federate_Name Absolute_Path_To_Fed_file

I created a poor man's synchronization using getchar, so you need to press enter in both federates after they have been started.

That simulation exhibits different behaviors if it is linked and run with CERTI using NULL Prime messages or not.

In order to avoid java thread mix in the log may be you can configure log4j to timestamp your log entry.

I'm just running 2 applications.

Yes Ok, but I was thinking more of a multi-threaded Java application calling jcerti simultaneously from

different path (in the same application). I'm not sure jcerti is ready for that so I was wondering whether

the trace of A federate could me intermixed or not.

That was the case for the first logs I send. A single process with 2 threads, each being a Federate. This lead to inconsistent (and unusable) log files.
That is why I backed to using two different processes.

David.