[MUD-Dev] Languages for MUD drivers

[Cynbe ru Taren]

"Ian Macintosh" <iman at issystems.co.nz> comments:

|  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 spent a fair amount of time thinking about (and coding!) such
stuff, and I fairly strongly agree that one definitive server owner
per given bit of state is the practical solution: The distributed db
people can offer alternatives, but imho they will prove too
heavyweight and too vulnerable to malicious denial of service attacks
to be effective in our sort of setting.

There are however lots of tricks which can be applied to reduce
hotspot problems, including:

* Marking state as read-only where-ever appropriate.  Read-only
  state can be widely cached and circulated between remote
  servers, reducing hotspot server load.  This may require
  something like public-key signatures on such state to guarantee
  authenticity, hashcode names to identify parts of it, and a
  server-server protocol for enquiring if a given bit of state
  happens to be in cache, please.

* Even where state is not actually read-only, it may be possible
  to mark it as cache-able for a period of minutes, hours or
  days:  This is basically the critical trick that makes DNS
  a practical engineer proposition instead of a cute theoretical
  idea.  Background descriptions (explicit or procedural) which
  get updated infrequently are reasonable candidates for this,
  and may easily constitute most of the state of many systems.
    Beyond the addition of the timeout, the implementation
  hacks are the same as for read-only state.

* Broadcast protocols can be used to make the load on a server
  independent of the number of clients.  Formal network broadcast
  facilities like MBONE can be cool in this context if available,
  but similar effects can be achieved by assembling clients into
  fanout trees:  Making the hotspot clients part of the load
  solution, not just part of the problem.  If this is done well,
  it effectively means that server hardware sources automatically
  scale to meet the load, since each client contributes resources
  to the server.

None of which constitute a magic bullet making all the problems
go away -- but since when does any kind of engineering work that
way anyhow? :)

 Cynbe



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