Re: [Mratc-developers] Things we need before implementing ATC

[<aqu...@ya...>]

 --- Michael Ross <ht...@us...> wrote: 
> ----- Original Message -----
> From: "Aquila Deus" <aqu...@ya...>
> 
> 
> > I have some examples:
> >
> > AtcToRadarInterface
> >   |
> >   |-- AtcToRadarRemote
> >   |     |
> >   |     |-- AtcToRadarRemoteViaHTTP
> >   |     |
> >   |     |-- AtcToRadarRemoteViaIPC
> >   |
> >   |-- AtcToRadarLocal   (which calls Radar functions locally)
> >         |
> >         |-- AtcToRadarLocalDebug (print everything on console)
> 
> Local vs remote abstraction can be accomplished at the IP
> addressing layer.  Want to talk to a process on the local
> machine?  Use the local machine's IP address.  Want to talk to a
> process on another machine?  Use that machine's IP address.
> It's just a matter of changing the IP address.

My "Local" there is actully to call the radar's functions in the same process,
not to call different processes on the local computer.

> 
> The closer the communication over the network is to self, the
> faster it happens, in a significant kind of way.  Pinging self
> takes maybe 0.03 ms.  Pinging a machine on the LAN might take 3
> ms.  Pinging something on the Internet might take 30 ms.  From
> this, we can see that IP communication with self is two orders
> of magnitude faster than talking with another machine on the LAN
> and three orders of magnitude faster than talking with a machine
> on the Internet.  The performance improvements gained from
> working closer to home are not lost in using IP networking for
> IPC.  Still, IPC (in any form) is more costly than keeping
> communications within the process.  We should try to keep IPC at
> minimum levels.
> 
> If we count database communications as IPC, I guess we will be
> doing a lot of it.  Database interfaces have undergone a lot of
> testing, debugging, and optimization, however.  They seem like
> robust and reliable channels for IPC.

Ah no. In fact my IPC means Unix's System V IPC only. Because there is shared
memory, which can require almost zero CPU time to communicate.

> 
> Rather than debugging to console, we might want to log to log
> files.  That's what Apache and MySQL do.  It is very effective
> in helping me understand what's going on in daemon processes
> that are not tied to a particular console.  Since all logging
> will be sent to a file in the local filesystem, there is no need
> for remote logging.  If someone on a remote machine wants to
> watch a log, they can secure shell into the remote machine and
> watch the log once logged in.  In Linux, this can be
> accomplished with the tail utility.  With it, a log file can be
> watched so that all new entries in the log show up on the screen
> as if the process were logging straight to the console.  I don't
> know if Windows has a utility like that.

cygwin :)

> 
> > BasicFlightRequest
> >   |
> >   |-- ChangeCourseRequest
> >   |
> >   |-- AirportRelatedRequest
> >         |
> >         |-- LandingRequest
> >         |
> >         |-- TakingOffRequest
> 
> I am not seeing much advantage here over structural-oriented
> programming.  All these communication requests can be
> accomplished in single, simple, flat http transactions.

True. It's not a good example :)

One reason to use inheritance is that when we're not sure what will be needed
in future, it's better to create a new class based on the base class rather
than to let the base class define things we will need/extend.

> 
> > > I could lay out a structure-oriented plan if you are
> interested.
> > > I've got one in my mind.  I just haven't felt the need to
> put it
> > > down in writing yet.  I was thinking I would just go
> straight to
> > > implementing the plan in database tables and code.
> Sometimes
> > > writing out decent plans is about as involves as writing
> actual
> > > code, so why not just go straight from ideas to code?
> >
> > How about write some scripts now and convert them to OO later?
> 
> Sounds good to me.
> 
> > I think we could code flight and radar simulation directly.
> And it may be
> > better to combine the two, since they are not our main
> business, and this
> > should reduce some complexity for ATC (one source to get info
> about flights).
> 
> We should code our simulators as close to the functionality of
> the real thing as possible, since aircraft and radar vendors
> will use them for network API and functionality guides when they
> implement actual flight control and radar systems.  It will also
> help us expose and address any problems that might be associated
> with that particular kind of design.

ok

=====
me = d2004xx = d2003xx = d2002xx


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com