Excellent analysis. This is why we have config files--to configure systems to the specific application of them.
In your example, personally I think the ideal response would be a hybrid of 1 and 3: step the clock so we're sane and continue and immediately dispatch the "repair" crew to find out what went happened because it might be something seriously wrong. In our situation, system uptime is less important than security. If there is any indication that security has been compromised (such as a sudden changing of the clock), the system should shutdown until someone can identify the bad behavior and ensure the system is secure. We do NOT want the system processing any requests if there is any question that there has been or might be a compromise. Flight dispatching is different--you want the system to run as best it can regardless if it is compromised. --- "David L. Mills" <[EMAIL PROTECTED]> wrote: > Your flight dispatcher machines are running just > fine and one of them > suddenly veers off course by one hour. Your > application is airt traffic > control. Your choices are: > > 1. Immediately shut down the timewarper and dispatch > a repair crew. > > 2. Force the timewarper to slew, even though it will > take a week to slew > within one second, your sanity limit. During most of > the week the warper > clock will be ahead of the rest by more than the > sanity limit. Of > course, a rew airplanes might collide, but will > crash in monotonic order. > > 3. Step the clock back, possibly confusing flight > planning, but at least > all planning is to the same clock and nobody > crashes. > > Comments from your database gurus, ALPA and PATCO > would be highly prized. > > Dave __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
