On Mon, Dec 26, 2011 at 12:07 AM, Martin Spott wrote: > There are different ways to prevent a service outage. Setting up a > second machine is just one of various different methods and you're > well-advices to have a precise look at the bigger picture, evaluate the > benefit against the drawbacks before advocating a certain method. > > The blunt "let's have a second machine"-approach might carry more > suprises than you probably think at first.
As it happens, this is an area where I've got quite a lot of professional experience. I don't think we have any requirement for additional scalability/capacity at this point - I'm fairly certain that a single server has no problem handling the peak load for FGCom. There's not much latency benefit from having a local FGCOM server if you're in a global MP environment and communicating with someone on the other side of the world (though there's more if the other party is local as well). However, we're talking about carefully worded radio comms - this isn't something for people to use instead of Skype. A second or so latency isn't the end of the world. Therefore the only argument for having anything other than a single server is for resiliency. Having multiple interconnected live servers doesn't buy us anything other than additional opportunities for the servers to lose connections with each other or suffer hardware faults. The probability of the server that _you_ connect to going down is the same as if there was a global server, and there's the additional probability that the server that someone else you are communicating going down. So, really, you just want a live server with some sort of backup. Fortunately no data needs to be stored/shared as the state information is minimal, as channels are created and torn down on connection. If we were feeling particularly keen, one might want to have a hot standby, and some shared global IP address that can be swapped. However, to do that properly requires a very reliably private network for the liveness checking between the servers, and to be honest is way more than we need. If we feel there's significant hardware failure risk, my recommendation would simply be to have a cold backup, and use a manual process to update DNS in the case of failure. -Stuart ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
