|
From: John W. <ca...@mm...> - 2001-09-07 15:18:47
|
Ahh, the perversity of it all... Getting ready to run some sims and tests to look at the net traffic, and the net crashes, the gateway is sick. After a little fussing with the firewall, things were back to normal The bottom line: (Good news) The net traffic looks just fine. Addresses are what they should be and all machines can send and receive UDP datagrams. One interesting exception; the wireless laptop cannot send data but it can receive. This might have something to do with the firewall inside the 3Com box setting/restricting certain privileges and services for wireless devices. The fact that Norman Vine's test program (http://vso.cape.com/~nhv/files/fgfs) receives the cur_fdm_state indicates that the io is working so the most likely problem is somewhere in the interface between the flightsim and simgear. (Not so good news) If you look at the code modules in External.cxx in the FDM directory you will see only placeholders, while the other models are"busy" exchanging data structures with Simgear. If the "external" option is envoked (see the fg_init function) then it would seem reasonable the data exchange would occur here. So broadcast works at the lower levels, the "cookie crumb trail" ends at External - nothing comes in and nothing goes out. I am considering adding some functionality to External.cxx to take network input and output it to the Simgear structures consistent with the other FDMs. There is some new code in the CVS respository in ../src/Network that Curtis has just added. Does this (should this) be coordinated? IMHO: The interfaces between the FDMs and Simgear should be consistent and External should be the place to enforce that consistency with the OSI Layered model. Machines communicating with simgear might be running on an IBM, an old VAX (very old), in Fortran, in Ada. who cares. As long as they meet the interface spec, they are welcome. Developers wishing to add additional features or calculations to the input would do so here within the walls of the External module. For example; in a former life I worked with the AFHRL folks in Arizona on a large flight sim project for air-to-air combat. The "enemy computer" would always win any engagement with a human pilot since it always had "perfect information" as to the adversery's state while the human had to estimate based on visual and radar observations. It was necessary to "dirty-up" the computer's channels to level the playing field. Regards Jack W |