Re: Thought for the day

From: Daniel A. Koepke (
Date: 06/17/00

On Fri, 16 Jun 2000, Mike Redick wrote:

> Ok, I've been thinking about this while in my Operating Systems class
> bored out of my mind. The problem with trying to save every event that
> happens so that you can restore the mud to the same point after a
> crash/reboot is that it will be slow.  The processor speed doesn't make any
> difference because the program has to stop and wait for the data to be
> written out to the hard drive, and hard drives are very slow.

Such persistence of world state has been discussed here several times, and
each time I say the same thing and everyone goes, "Hmm, yeah," and then a
few months later we're back at it going, "Wouldn't it be cool if...?"

My traditional response has always been that world state _MUST_ be stored
separate of the game server for such complete persistence to work.  One
very simple approach would be to mmap() the world in the first place and
occassionally sync the disk and in-memory images.  This is very a quick,
reliable method but has several problems: first, there's no good route for
recovery if some persistent data is munged.  You'd need some way to
rollback mistakes, and that becomes complex really quick.  Second, your
world state would be platform-bound.  Different platforms undoubtedly map
memory to disk differently.  There may be clever ways around this latter
little bit, but it's probably not worth it.

Better than having a separate process specifically for managing world
state through memory mapping, is to just use an existing database.  For
instance, MySQL or PostgresSQL or any other SQL server you might have
available.  These databases often offer rollback and other services, in
addition to being relatively simple to switch platforms with.

This might all be reaching the point where it belongs in the FAQ, as I
know I've personally offered the same solution (and, indeed, I believe it
to be the _best_ solution) several times.


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

This archive was generated by hypermail 2b30 : 04/10/01 PDT