20,741
edits
Telnet usage: Difference between revisions
Jump to navigation
Jump to search
no edit summary
mNo edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{PropertyTree}} | {{PropertyTree}} | ||
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, these built-in daemons support multiple connections. [[FlightGear]] comes with an internal command server. This so called '''"telnet" server''' provides a "remote shell" (like a command prompt) into the running FlightGear process that can be used to inspect and modify runtime state, but also to run commands. | |||
FG has a low bandwidth "command" (aka telnet) interface where you can interactively (or automatically via an external program) examine and modify just about any internal variable in the sim. This gives you a great capability to do external scripting, external operater gui's, etc. For instance, if you have your own GUI for operating the sim and want to use it to set weather conditions, you can leverage the FG telnet interface to have your own program remotely configure the environmental settings in all your FG based visual channels. | FG has a low bandwidth "command" (aka telnet/props) interface where you can interactively (or automatically via an external program) examine and modify just about any internal variable in the sim. This gives you a great capability to do external scripting, external operater gui's, etc. For instance, if you have your own GUI for operating the sim and want to use it to set weather conditions, you can leverage the FG telnet interface to have your own program remotely configure the environmental settings in all your FG based visual channels. | ||
Many things (view parameters, weather, time of day, etc.) are configurable via the property system. For things like weather and view selection which don't change rapidly, you can send over new property values using the "telnet" interface. For things that could change rapidly (like view position/orientation) you probably want to blast over udp packets at 60hz or whatever your screen refresh rate. | Many things (view parameters, weather, time of day, etc.) are configurable via the property system. For things like weather and view selection which don't change rapidly, you can send over new property values using the "telnet" interface. For things that could change rapidly (like view position/orientation) you probably want to blast over udp packets at 60hz or whatever your screen refresh rate. | ||
The -- | The telnet server can be activated with the <code>--telnet=port</code> [[Command Line Parameters|command line option]], where port is the number of the listening port that will be opened locally by the FlightGear fgfs process (note that the --props parameter is equivalent). | ||
The --telnet= option can be used to accept property configuration changes (things like weather effects and time of day.) You can use this interface to read/write individual properties. You could set up a separate gui configured to know the ip addresses of all the slaves so it could update them appropriately to make a change. For the time of day, this presupposes that all the computer clocks are pretty closely in sync ... then you can send the same time offset to them (in seconds) so they all can display the same time of day effects. | |||
A connection to the running server can be established using a conventional telnet client or by opening a simple TCP socket from a custom program. | |||
Using a telnet client (such as [http://www.chiark.greenend.org.uk/~sgtatham/putty/ Putty] for Windows) it is possible to connect to a running FlightGear process and issue commands that FlightGear then runs internally. | Using a telnet client (such as [http://www.chiark.greenend.org.uk/~sgtatham/putty/ Putty] for Windows) it is possible to connect to a running FlightGear process and issue commands that FlightGear then runs internally. | ||
The telnet client can be running on the same machine as FlightGear itself, or on other machines that are in some way connected to the same network (LAN, WAN/internet). | The telnet client can be running on the same machine as FlightGear itself, or on other machines that are in some way connected to the same network (LAN, WAN/internet). | ||
| Line 16: | Line 16: | ||
This can for example be used to read and set values within the [[Property Tree]] structure, but it can also be used for running [[fgcommands]]. | This can for example be used to read and set values within the [[Property Tree]] structure, but it can also be used for running [[fgcommands]]. | ||
A list of available fgcommands is available in <tt>[[$FG_ROOT]]/Docs/README.commands</tt>. | A list of available fgcommands is available in <tt>[[$FG_ROOT]]/Docs/README.commands</tt>. | ||
This makes it possible to "remote control" FlightGear by using the telnet protocol. This can for example be used to change environment settings (weather, time, visibility etc). | This makes it possible to "remote control" FlightGear by using the telnet protocol. This can for example be used to change environment settings (weather, time, visibility etc). | ||
But a telnet connection can also be used for inserting scenery objects or [[Interactive traffic|AI aircraft]] models dynamically. It is also possible to trigger arbitrary [[Nasal]] code by writing to a property with a registered Nasal listener. In fact, it is even possible to insert and run Nasal code via telnet, by writing the code to a property and call()'ing it then [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00150.html][http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00965.html]. | But a telnet connection can also be used for inserting scenery objects or [[Interactive traffic|AI aircraft]] models dynamically. It is also possible to trigger arbitrary [[Nasal]] code by writing to a property with a registered Nasal listener. In fact, it is even possible to insert and run Nasal code via telnet, by writing the code to a property and call()'ing it then [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00150.html][http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00965.html]. | ||
Multiple connections are possible at the same time. For an example in Java please refer to [http://gitorious.org/fg/flightgear/blobs/next/scripts/java/FGClient/src/FGFSDemo.java $FG_SRC/scripts/FGClient]. | Multiple connections are possible at the same time. For an example in Java please refer to [http://gitorious.org/fg/flightgear/blobs/next/scripts/java/FGClient/src/FGFSDemo.java $FG_SRC/scripts/FGClient]. | ||
| Line 29: | Line 25: | ||
For shell scripting purposes, [http://netcat.sf.net netcat] also works well. | For shell scripting purposes, [http://netcat.sf.net netcat] also works well. | ||
In comparison to the binary native protocol, the props/telnet protocol is a lower bandwidth, high reliablity channel. You are guaranteed that every message gets to the | The routines already support network byte order, however there are cases (i.e. interfacing to an external perl script using pack/unpack, where network byte order is not desirable). | ||
In comparison to the binary native protocol, the props/telnet protocol is a lower bandwidth, high reliablity channel. You are guaranteed that every message gets to the receiver once (and only once.) This is great for setting up weather conditions, time of day, camera parameters, and anything else that might have an impact on the visuals. We have a convenient "telnet" interface to all the internal properties and built in commands. Anything you can set from the keyboard, or mouse, or gui, you can do from a remote program or script. It's much lower bandwidth, but very convenient. | |||
The telnet mechanism is not designed to be high bandwidth. I believe it runs at 5hz? and only processes one line/command per iteration. You could try upping the frequency via the command line, "--props=socket,bi,20,,5500,tcp" (we could change PropsChannel::foundTerminator() to handle several | The telnet mechanism is not designed to be high bandwidth. I believe it runs at 5hz? and only processes one line/command per iteration. You could try upping the frequency via the command line, "--props=socket,bi,20,,5500,tcp" (we could change PropsChannel::foundTerminator() to handle several | ||
commands per line. Commands could be separated with semicolons. Or perhaps some commands could take more than one argument, eg "get /foo/bar /foo/baz"). | commands per line. Commands could be separated with semicolons. Or perhaps some commands could take more than one argument, eg "get /foo/bar /foo/baz"). For higher bandwidth needs, it would work better to send over an FGNetFDM structure (src/Network/net_fdm.hxx) via UDP or some other custom structure. | ||
== Telnet Server == | == Telnet Server == | ||