martin pardee wrote:
harald,
thanks for the pointer. just one question though: what role does the FG
client" play in the system? (if the answer is that i should go read the code
and find out then i'll go do that).
Client, server, master, slave are overloaded buzzwords. :-)
FlightGear can be configured to act like a telnet or even an http "server". It can watch a port for incoming connections and respond appropriately.
FlightGear can also be configured to dump UDP or TCP data packets out over the network at a high speed. Other copies of FG can be configured to read these packets and use that data (and disable the internal dynamics calculations.) In this case, depending on your command line options, FG can be configured to be a telnet server, an http server, a "dynamics" master/server, or a "dynamics" slave/client, and possibly some combination of all of those simultaneously depending on the context and what you are trying to accomplish.
it sounds like FG is set up to "talk" to another process over the net,
Yes, with several approaches and mechanisms supported. Different approaches are best suited for different uses.
treating that process as a netwrok client in the classic 2-tier "client-server" model.
Yes, we can do that.
if this is correct, then it suggests that my hardware interface software is going to place requests (via telnet) to the "server", e.g. FG, and ask for the contents of member variables that hold frequency data, and submit "event notifications" when i've moved a control knob on my hardware.
how am i doing so far?
Yes we can do it that way. Using the telnet interface, your own custom client software can request the value of any variable at any time. You can also update the value of any other variable at any time. The overall bandwidth of the telnet interface is not very high though so it's not appropriate for blasting all the flight dynamics data at 60hz for instance, but for your application it probably will work very well ... and I can imagine ways to cheat that would make it look like it was working even better than it actually was. (For instance, you might get some delay if you turn the knob, send the data to FG, and then read the new frequency back from FG, but if you know locally how far your knob turned, you can update your local display immediately, and then sync up with FG at a slower rate.)
Regards,
Curt.
--
Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
