[MUD-Dev] World Persistence, flat files v/s DB v/s ??

[Orion Henry]

At 09:12 PM 3/25/98 PST8PDT, you wrote:
>On Tue, 24 Mar 1998, Adam Wiggins wrote:


>> Naturally the only downside to this is that you essentially need double
>> the RAM, but I see this as a pretty small concession, considering the price
>> of memory these days.
>
>The crucial part you are missing here, is how to do the snapshot?  You
>still have to pass (copy) the data, either through a pipe or socket
>or something.  It would probably be about as quick to just write it to
>disk...  Of course, I could be wrong...
>
>Ben
>

This is where you can have a little fun.  These records are people...
places.. things... whatever you need to use for your mud.  Each contains
references (unique ID's, not pointers) to other records.  Lets say that the
back end process ( the one that holds the "snapshot" ) holds a huge number
of records and the ones it dosnet have RAM for (if you dont have enough)
are written to disk.  Your front end process (the MUD) holds less, say
MAX_RECORDS.  Each time a refrence is dereferenced it checks the local
cache and if its not there its requests it from the back end process.  When
the number of local records exceeds MAX_RECORDS it drops the oldes ones (
LRU or Clock algorithms will do nicely).  Now dont panic... I see the
problems with this too.  There's more.

1) Whenever a record's reference is dereferenced, the front end process
fetches all the recrods associated with it... Thus, when you dereference
Boffo the Half-Troll you also bring over his moth eaten shirt.  His deadly
tree branch.  His manky underwear and the room he's in.  (because you will
proboly reference all of this very shorty after looking at Boffo) This way
when you make a reference its (probobly) always there...  

2) Whenever a record is changed it is marked as dirty and schedueled for
upload back to the back end... otherwise its just forgotten when it falls
off the LRU list.

Thus you only download from the backend the items you are useing and only
take a snapshot of the ones that change.

In the case of a crash, the process goes down (really quick)  It reboots
without any data (really quick) It recovers the still open descriptors to
the players ( really quick)  and it grabs the records for the players bodys
(wich prefetches the things they have and the rooms they are in) (also
quick since theres only a few records here) and thus you can reboot in
possibly under a second.   The DB is also current to the last write of
dirty records to the database (theres no reason this cant happen very
often) and if all goes well the crash seems like a second of netlag to the
players.  The mud is up and running (with maybe a 100 records for the
players and their eq and the rooms they are in...) and as they start to
move around and interact with the world all the thousands of records start
to migrate back from the back end...

The higher you set MAX_RECORDS the better the performance you get,  if you
have enough RAM for two full coppies of the mud and all its records then go
for it.  What you gain is the ability to reboot (possibly without the
players noticeing) and all you loose is the time it takes to upload dirty
records...

Sockets and pipes would work well for this but (I'm not sure) but I think
that unix messages will be very fast for this implimentation.

	Orion