You might want to go to the TNL website ( 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!!!

John W.

----- 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?
> Ampere
> 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
> >
> > 2f585eeea02e2c79d7b1d8c4963bae2d
> _______________________________________________
> Flightgear-devel mailing list
> 2f585eeea02e2c79d7b1d8c4963bae2d

Flightgear-devel mailing list

Reply via email to