Re: [certi-dev] CERTI billard test / http_proxy

[Eric Noulard]

2009/5/22 Martin Spott <address@hidden>:
> Eric Noulard wrote:
>> 2009/5/20 Martin Spott <address@hidden>:
>
>>> [...] I'm just wondering why the setup
>>> fails to join yet another 'billard' into a system that's already
>>> executing. Whenever I try to join another one, it hangs at:
>>>
>>> foehn: ~> billard -fTest -FTest.fed -n X
>>> CERTI Billard 3.3.3cvs
>>> with TIMESTAMP. If you want without TIMESTAMP add -e option.
>>> BILLARD Note : FederationExecutionAlreadyExists Reason is : . OK I can join 
>>> it
>>> Display(400, 265, 500, 100)
>>> Synchronization...
> [...]
>> This is definitely a billard bug, I think it should have worked in the past,
>> we'll look into it.
>> Bug filed:
>>  https://savannah.nongnu.org/bugs/index.php?26640
>
> Ah, ok. Please remind that I'm in no way attempting to blame you on
> bugs in CERTI or its utilities.

Got that, I wasn't taking it as a blame, my moto is
"one more bug may be one bug less for the next release".
Thus, I think it's really a bug.
It wasnt' caught before because we did not systematically test this pattern
we should add this test to our test suite.

> Instead, what you see here, what
> results in questions like these is actually me taking the 'empiric'
> approach at learning how things are supposed to work, one step at a
> time. I'm simply trying to understand the inner workings as much as
> possible (at least to a reasonable scope) before I start building test
> cases using Petr's "VirtualAir" HLA interface with FlightGear.

>
>> If you want to know more about HLA sync point keep reading,
>> if not just skip the rest of this message.
>
> Even though this sort of handshaking models is not entirely new to me
> (occurs all the time when you're analyzing TCP-based or other network
> communication) it's still been an interesting read.
> Thanks a lot,

You are welcome.
One more piece of information.
CERTI internals are message based.
Message sent to/from Federate to/from RTIG may be traced
if you

export RTIG_MSG=D

in the appropriate terminal (RTIG, billard, etc...) will make the reception
and sending of those message to appear. Most of them have clear meaning
some needs more knowledge.

The current trace format is not easilly parsable but we are working on something
more useful, based on XML.


-- 
Erk