[MUD-Dev] Languages for MUD drivers

[J C Lawrence]

On Thu, 18 Nov 1999 12:39:12 +1300 
Ian Macintosh <iman at issystems.co.nz> wrote:

> The reason why I believe this is better than using RPC or whatever
> to load balance based on events, is that I can't get away from the
> requirement that one system has to be the master, or own, a
> particular piece of the MUD.

> i.e., Server B handles Midgaard, and as such, if *anyone* or *any
> server* wants to know the exact state of Market Square, it must
> find out here.  If there are two servers possibly handling the
> same piece of real estate, who's version is the right one?
> Likewise, Server E controls the Grand Mistress of Magic sitting on
> her throne in the High Tower of Sorcery.  If you want to know her
> status, you find that out by querying Server E.

I've been tending towards a very different view:

  There is (but doesn't need to be) a large DB server which holds
the master default copies of everything modulo latency for updates
(interesting transaction model required) the world.

  There are some number of game servers which process players and
other active items (I don't distinguish) in the game world.  Data,
ad defined by the location assumed to be "master" migrates
dynamically across the pool of game servers for maximal proximity to
the processes dealing with that data.  This is where the DB server
becomes irrelevent.  It isn't actually needed.  I only posit it as a
simple target for state checks and backups.

  Processes dynamically migrate across and around the pool of game
servers for maximal proximity to other processes with similar
working sets.

  Processes dynamically migrate to unused game servers in search of
more available resources (standard auction-style bidding war server
competition for client processes).

  One of more connection servers act as IO aggregators in dealing
with client/server data exchange and to resolve the problems of port
migration and single service presentation apparencies.

The sad part is that real CS is needed to get this right.  Amusingly
enough in many ways the problems are rather close to those addressed
by some CC:NUMA architectures (cf SGI's Origins).

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev