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!!!
Regards
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
you
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
be
the server in this case or will the clients be able to communicate with
each
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
able
to log into the network again to continue the flight?
Assuming that each aircraft only has one crew, and that he/she can
reconnect
to the system to continue the flight after a disconnection, what will
happen
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
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
