[MUD-Dev] Languages for MUD drivers
Cynbe ru Taren
cynbe at muq.org
Thu Nov 18 01:58:31 New Zealand Daylight Time 1999
"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? :)
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev