Welcome to FlightGear Deamon fgd
--------------------------------
Here the first Tools to play with FlightGear Deamon.
This is yet alpha moving to beta and the sources remain to be tidied up,
and to get documented.
Why this software?
------------------
The goal of the author is to keep unnecessairy jobs out of FGFS. This keeps
FGFS doing what it should do: simulate!
Adding more fancy stuff into FGFS would maybe spoil it's framerates and lead
to larger compiletimes. For that reason an external solution comes in quite
handy. Firing up the deamon on another machine than FGFS is running does not
affect the cpu-time of FGFS. Let the deamon do all the other jobs for your
FGFS, also let *him* communicate with the outer world and present the
results in a "precooked" way.
Theory of operation:
--------------------
The FlightGear Deamon, called fgd, is a standalone program which registers
FGFS players willing to have a multiplayer FGFS environment via TCP/IP.
Information like player's IP/lon/lat/alt etc and also messages can be send
to fgd.
The deamon fgd in turn sends back the gathered information upon request.
The purpose of the scan prog "fgd_scan" is to locate free ports on the
network, which can be used for exchanging data between FGFS and fgd.
The commando program "fgd_com" serves as an example of how the communication
to fgd can be done. For the moment, the functionality of fgd_com is not yet
integrated into FGFS. Parts of fgd_com will be later incorporated into FGFS.
The master control program "fgd_mcp" is some sort virtual fgfs. It simulates
up to x FlightGear simulators. It's main purpose is being a development
platform for network related stuff. The coolest advantage here is the
possibilty of having multiple fgfs's in one little program. That saves *much*
memory and also time because recompiling fgd_mcp is way faster then FGFS.
How to play with the tools:
---------------------------
Just fire up fgd on whatever machine reachable from the one on which FGFS
will be running. Even the same machine is ok.
Then use fgd_scan to locate the fgd-deamon.
Also use fgd_com to pass some commandos to fgd.
Try setting up various scenarios with fgd_mcp and see if everything works.
How to compile:
---------------
Have a look at the HEADERS file and check the presence of the required headers
on your machine and adjust them in the fgd.h file just in case of being located
elsewhere. This software is libc5 proof, so maybe on glibc (>=2), the header
files will be located elsewhere.
Use the Makefile with make or just gcc -o prog prog.c
Default location for "make" is current directory, so be sure to have r/w-access
to it. For "make install" you have to be root, binaries go by default into
/usr/local/bin.
Usage:
------
- fgd [start port] [end port] [name] <-v -vv>
where
- start port and end port is the (numeric) range where it should
listen and talk to. (Later the range will be used to check for a
free port within this range, which can be used for communicating
with FGFS.
for the moment make sure you use the _SAME_ port value for start
and stop. A good starting point should be above or equal 10000.
- name (string) of the deamon.
- -v or -vv is the verbose level. This param can be ommitted.
Be careful, trying fgd on a used port doesn't work. Also it doesn't
make any sense and luckyly doesn't goof the service of the used port.
Just in case you did fgd will complain and advise you to look for an
unused port first.
- fgd_scan [host] [start port] [end port] <-v -vv>
comment: params are the same as for fgd except that the start/stop values
should be different to detect fgd. In case of knowning the port,
which fgd uses, one should of course set equal port-values.
Also host means the host running fgd, not where the scanner is
fired up.
Just for fun you can take also the dangerous (priviledged ports)
But the fgd-scanner could maybe get stuck at some used ports.
It doesn't hurt to experiment in the used regions, a ctrl-c
will abort the scanning so that new params can be used.
ACHTUNG! A well configured system, in this case the target-ip the
scanner inquires, will log the replies of various services
trying to react to the scanner. It depends on the vigilance
and mood of the respective sysadmin what will happen to the
*evil* person sending requests to the target system.
Scanning unused ports doesn't hurt at all.
Have a look at the "/etc/services" file which describes all
the "official" services & deamons lurking on various ports.
- fgd_com [FGD-host] [start port] [end port] [-v -vv] [commando] <FGFS-host>
comment: like fgd_scan, but you must enter either an ip (numeric) or alias
(string) or a fqdn (like foo.bar.com) or dummystring as last parameter
here: <FGFS-host>.
Some commandos use it to pass it as real information to fgd. Maybe the
start/end port options will go away later because it's the job of the
scanner to find fgd within a range.
It's a waste to spoil the net with commands (tcp-packets).
- fgd_mcp
comment: works like fgd_com except that it is *not* a single shot program as
the other programs, yes it works interactively so you have to enter
all relevant values yourself at runtime. You can stresstest any
FlightGear deamon to see if it responds a) accurate b) fast enough.
You can enter a Flight route just by entering the start/stop coords
and the speed. This master control program will then automagically
send information about current aircraft to the deamon, like a real
FGFS would do.
You can even define multiple scenarios. That means that all defined
aircrafts fly simultaneous at the same time.
Relevant params here are alt, lon, lat, speed, roll, pitch, yaw,
pilot, model, start/stop-coords and update frequency.
Watch out for broken pipes, never had any in a xterm but often on
text consoles. They will go away when the "recv"-loops will be
replaced by "select"-calls.
The default values suit my personal needs. So don't be paniked if
you get some errormessages. You just have to adjust some values
like IP's and HOST-names in either sourcecode or to enter them at
runtime.
The commandos for fgd_com:
--------------------------
0 : fgd identifies itself and answeres back to scanner
1 : registering to fgd
2 : show who's registered
3 : send message to one specific user (not implemented yet)
4 : send message to all users (not implemented yet)
5 : scan for other fgd's (not implemented yet)
6 : push (fgd_com sends FGFS-data to fgd) (not implemented yet)
7 : pop (fgd_com receives data from fgd) (not implemented yet)
8 : unregister from fgd
9 : shutdown fgd
Comments:
---------
Commandos 1/2/8 use the last parameter (see above, dummy-string) for the
ip or hostname or fqdn of the fgfs-machine which will be added/listed/removed
from fgd.
Commandos 3+4 are some sort of "talk" to registered users on fgd.
The messages are keyed in, then send and stored into fgd until the
recepient user requests fgd data via command 7 (pop).
Command 5 scans the net (within a range given) for other fgd-deamons.
Commandos 6+7 are seperated send/receive requests to/from fgd.
Later it will be FGFS who queries fgd in given intervalls. By now it's
the user who sends/receives at will via menu or keyboard while flying.
Command 9 is a remote shutdown for fgd. This at least avoids telnetting
to the remote machine, where fgd is fired up. Caveat Emptor: be careful,
everybody connected to fgd can send the "fgd-shutdown"-command. And hey,
also everybody can unregister another user...
Since all FGFS pilots are friendly and Multipilot-mode is considered
cooperative rather then deathmatch, I don't expect any malicious mis-use
of Multipilot-mode, err...yes? Also this keeps me from adding foolproof
if/then/else-stuff because FGFS is a serious Simulation Software used by
serious people who *know* what they are doing, even if they store FGFS in
directories like:
/usr/games/fgfs or D:\SPEL\FlightGear or /home/olk/spiele/fgfs
Try registering and unregistering various hosts to see if the add/remove
mechanism works well. It should work correctly as it can be veryfied
with the "2" command.
Examples:
---------
- fgd 10003 10003 Johnney -vv
fgd runs locally on port "10003" called "Johnney" using max. verbose level
- fgd_scan olk 1 1024 -vv
scans for flightgear deamons on host "olk" using ports "1" thru "1024"
beeing very verbose. Using ports below 10000 is, err...you know.
- fgd_com olk 10003 10003 -vv 1 johnny
send "register host"-command to fgd running on host "olk" using port"10003"
and register machine "johnny", here "johnny" is a fqdn.
- fgd_mcp (without any commandline params)
To do:
------
- modify FGFS to talk to fgd and display the data on HUD and draw any found
pilot's aircraft within visible area
- porting to Mac and Windows(95/98/2K/NT)
- clean-up code
- replace "recv"-loops by "select" (blocking vs nonblocking discussion)
- concatenate the elements of one command into one single net-call instead
of sending each element seperately !!!
- reducing of data to be transfered - here: wiping out redundancy,
computers can be upgraded easily but upgrading the bandwith of the net is
almost impossible ;-((
- document the code
- convert code from c to c++ ?
- find a place within FGFS, where to reside
- make fgd a *REAL* deamon which is forked in background
- make fgd concurrent instead of iterative, hmmm...
- make the code more autodetectable, to reduce commandline params
- implement missing commands
- find other useful commands
- find and resolve bugs ;-)
History:
--------
v0.1pre-alpha: May 25 1999 -> First release
v0.1-alpha : Nov 08 1999 -> Introducing fgd-Master-Control-Program
Some cleanups, implementing missing commands
of fgd_com into fgd_mcp
Nov 29 1999 -> Implementing scenario functions like virtual
Pilots
Nov 30 1999 -> ???
v0.1-beta : Jan 16 2000 -> Several libc5, glibc-2.0 and glibc-2.1
issues cleaned up
Future Plans:
-------------
Adding support for downloading files from Webserververs or FTP sites,
eg. weather data (METAR) and passing the infos to FGFS.
Adding some sort of "Tower Control" to the deamon. It could for instance
calculate the nearest airport for each pilot.
Modifying FGFS in a way to accept foreign-data. A so called remote-used
FGFS could display another view of the same flight. Well this requires
at least two or more machines, err...hummm.
On the other hand a remote used FGFS could serve as a teaching facility,
watching somebody else's fly could be very instructive ;-)
Another idea is to implement "black box" features into fgd. The deamon
would serve here as a flightrecorder. By this one could review a past
flight or any flight recorded by somebody else. The recorded "scenario files"
could be read by any deamon and serve as input data for any FGFS switched
into remote mode, see above paragraph.
Thanks:
-------
- W.Richard Stevens+, for his fantastic Unix Network Programming books
- Tennessee Carmel-Veilleux, e-mail: veilleux@ameth.org, for his portscan
program which inspired me writing the FlightGear metwork support.
REMEMBER:
---------
Those 4 toys are alpha and dirty and need also to be documented.
The programs are fairly well tested under Linux only, but the code should
conform to Unix98.
This software is OPEN SOURCE SOFTWARE, this helps to avoid this package to
be involved into _EVIL_ discussions about copyrights etc...
You can do whatever you want with this software, even enhance it.
Send comments/flames/BEER/whatever to delise@mail.isis.de
Oliver Delise Jan/16/00
