You might want to go to the TNL website (www.opentnl.org) and most of those
questions are answered in the docs.
There are error/fault recovery procedures to handle such things and its just
a question of how robust we want to make the network. And that depends, in
part, on the size and interest of the community to support on-going
development and operations. Few users -- forget it!!! Lots of players,
heavy net traffic -- we make it industrial strength!!!
----- Original Message -----
From: "Ampere K. Hardraade" <[EMAIL PROTECTED]>
To: "FlightGear developers discussions" <[EMAIL PROTECTED]>
Sent: Saturday, October 02, 2004 10:51 PM
Subject: Re: [Flightgear-devel] Re: [OpenATC] Re: status
> Here are a few questions:
> What will happen if the ATC is disconnected? What sort of redundancies do
> have in mind? Who will handle all the traffic when no one is the ATC?
> How does a client knows about the location of other clients? Will the ATC
> the server in this case or will the clients be able to communicate with
> other directly?
> What will happen if a pilot is disconneted due to a computer crashed or
> seg-fault? Should the aircraft be blinked out, or should the pilot be
> to log into the network again to continue the flight?
> Assuming that each aircraft only has one crew, and that he/she can
> to the system to continue the flight after a disconnection, what will
> if the pilot gets disconnected during a take off/landing? Should the
> aircraft automatically abort the procedure or should a computer from
> somewhere handle the rest?
> On October 3, 2004 12:53 am, John Wojnaroski wrote:
> > Well, there has been some progress on implementing an OpenATC protocol
> > based on the tnl library.
> > Putting together a package that will create applications for master
> > server nodes, controller nodes, and pilot nodes. If your comfortable
> > with the FG/SimGear directory structure and build process you should
> > feel right at home with this package.
> > ATM controller nodes announce their presence on the net to the master
> > server which acknowledges their presence and logs them into the
> > controller list. A pilot node request service from the master server by
> > announcing a set of parameters( location, freqs, callsign, etc) and the
> > master determines based on TBD criteria which controller node on the
> > list has control. And establishes a two-way link for the
> > pilot/controller pair, updates the log/connectivity/whatever tables. The
> > master bows out and the pilot/controller pair now directly exchange data
> > as required (for now, this is just a bunch of nonsense encrypted data,
> > although the hooks are there to get FG data). There is nothing on the
> > controller end that knows what to do with the data.
> > We're still a long way from a functional system, but it looks like the
> > underlying backbone network stuff will work. To that end I'm thinking
> > of setting up a limited network test to watch the whole thing come
> > crashing down ;-). Actually, I've brought up the network using a couple
> > of IP addresses I control and several internal machines on a LAN. The
> > protocols provide for a reasonably good level of security and will allow
> > cooperating nodes to connect from behind firewalls and NATs in a secure
> > manner.
> > It needs a bit more work to make it look more ATC'ish, but it might be
> > time for a proof-of-concept. So looking for a few good volunteers to act
> > as pilots and controllers. Will need to work out the details of how,
> > when, who, and what...
> > Regards
> > John W
> > _______________________________________________
> > Flightgear-devel mailing list
> > [EMAIL PROTECTED]
> > http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> > 2f585eeea02e2c79d7b1d8c4963bae2d
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
Flightgear-devel mailing list