[MUD-Dev] Re: TECH: Distributed Muds
bwh at wksoftware.com
Thu Apr 19 17:58:12 New Zealand Standard Time 2001
At 06:42 PM 4/19/01 -0400, Derek Snider wrote:
> True, it would be rather on the expensive side, but I'd think that
> games that expect to support 100,000 or more simultaneous paying
> customers should design around this sort of hardware, no?
You lose scalability, and price/processor is still ridiculous with the
high end Sun and SGI enterprise servers.
If you design your server architecture such that you're counting on
features of SMP (shared memory access, assuming reasonably fast
interprocess communication, etc.), at some point you won't be able to
add more processors because you hit the architectures max. And you're
left with a huge legacy hardware investment that you can't get rid of
5 years later.
You also lose the flexibility of doing "temporary scalability" by
temporarily adding more computing resources when you need them. Once
you buy that 8-CPU board, you're kind of stuck with it and won't be
using it elsewhere.
The far more general solution is to use networked sets of single or
dual-processor machines that can be put in high-density rack mounts.
Price/processor with commodity components isn't too bad; you can have
a heterogenous environment if you make TCP/IP your IPC mechanism; you
can downgrade/upgrade in a piecewise fashion; and you can redistribute
computing resources as you need by simply moving machines between
Obviously, clustered solutions are going to lose in most situations
when compared head to head against a similarly configured SMP system
because the SMP system is going to have a much faster interprocessor
backbone and other efficiencies from having a shared memory
architecture (e.g. static world data can be loaded once and shared
amongst all processors, so you probably don't need nearly as much
total memory in an SMP system as you do with a cluster).
However, when you take into account the practical considerations
inherent with using clusters, they make a lot more sense. They burden
the server architecture a bit because you have to assume a
(relatively) low bandwidth, high latency form of IPC, but that's
probably a worthwhile trade off.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev