[MUD-Dev] [Tech] MUDs, MORPGs, and Object Persistence

[Bruce]

Kwon Ekstrom wrote:
> From: "Bruce" <bruce at puremagic.com>

>> But there are plenty of things that aren't done well by existing
>> codebases (at least in released versions).

>>   * Monitoring/Logging systems.

> *nod* I've always hated how poorly logging was done on every mud
> I've worked for... It's one of the major things I'm working to
> improve on my system, I intend to store logs in memory, which will
> phase out to a temp file, and eventually get deleted.  The major
> features I'm allowing is for Logs to contain additional data than
> just the brief description.  I'm also planning on attaching logs
> directly to certain types of reports (punishments, board notes,
> etc), as well as being able to send a log to someone who would
> otherwise be unable to view it (to show a player that yes we do have
> proof they did something, or to ask advice from visiting admins)

I don't mean logging of things that users say or do at a high level
within the game world.  I'm thinking much more of logging low-level
things within the server.

For example, in Cold, we can turn on logging options at runtime that
log things within the DB code such as:

  * Read in an object
  * Forced to write an object out due to cache overflow
  * Cache is synchronized to disk
  * Skipping of writing out dead objects

We can also log interpreter stack traces when we do something that
marks a particular object as dirty.  (Sometimes, we've discovered that
an object was getting written out and we'd thought it was read-only.)

We can also log interpreter stack traces whenever we allocate memory
in sizes over some given threshold value.  This helps us to find some
run-away storage facilities in a running DB, possibly buggy code that
is chewing up memory, etc.

As we go through various systems and fix bugs in them or rewrite, we
look at what we might want to be able to log.  It has been of great
value to us so far in debugging not just the driver code, but the
DB/mudlib code as well.

At the same time, I'd love to have far better logging than we've been
adding.  But I've been lazy and haven't had the time to write a small
library that did the various logging things that I wanted (in C):

  * Multiple log channels, configurable and manageable at runtime.
  * Multiple log levels, with differing levels per channel.
  * Ring-buffers, file-back log channels, maybe even shared
    memory access to ones that were in-memory only, syslog.
  * Could hook up to a logging monitor, through shared memory,
    tail -f on the log file, whatever, to perform notifications
    of critical events, via pager, email, instant messenger.
  * I'm sure I'm missing other useful features.

I've looked a bit, but didn't see any libraries that did all of that.
I didn't really want to use syslog directly as I wanted to maintain
portability to non-unix platforms, and I didn't think it could do
everything that I wanted.

I'm starting to amass a list of small libraries like this that I wish
I had, or that I have in bits and pieces here and there between
various projects.  I'm sure that most other people who are interested
in the more advanced types of server features that have been discussed
here lately could use some of the same things.

>>   * Unit tests.

> Could you be more specific by what you mean by unit tests?  There
> are a variety of consistancy tests that would be nice to have :)

I was using it more to signify testing the APIs of modules within a
system, and as more of a static thing, where we run a test suite after
making changes, rather than tests which are constantly being performed
at runtime, like pre- and post-conditions.

>>   * Use of transactions (with the sorta-exception of DGD with its
>>   atomic methods).

> I had thought about using a transactions type system for my server,
> but I don't think that I'm going to for various reasons (mainly
> because I'm spending enough time adding other "nice" but
> "unnecessary" features).  Although I think a transactions system
> would be wonderful to aid in synchronizing data.  Perhaps if I ever
> get around to distributing my server I'll add in a system to handle
> this.

It is unfortunate that many people want to only associate
transactional systems with distributed systems.  Any time that you are
making changes to data where something could abort that process before
the changes are finalized and written back to storage (be that
in-memory or on-disk), you could probably use a transactional system.
(I know that that encompasses just about every bit of running
software. :)

>>   * DB robustness in the event of server failure.

> This covers alot, unfortunately I can't say that my DB fits this
> bill, although my server is extremely robust.  Using java exception
> handling I've only managed to bring the server down once... um, that
> happened

That's just one failure mode for your DB though.  You could get
corruption due to many things, like the file system filling up and a
write going bad, a power failure in the midst of a write, etc.  Some
of that can be addressed by ordering of operations, some by explicit
code within the application to help maintain consistency (more on this
in a month or so, as we've found a way to make Cold do asynchronous
cache flushes to disk and to maintain far far better consistency of
the on-disk DB), and some by maintain transaction logs.

It is also a LOT of work to ensure that the DB code is correct and
that you've really gotten the failure modes under control.  Do any of
the existing codebases that are publicly available do this well yet?

>> Other things, like distributed servers, capability-based security,
>> or clustering are roughly understood, but the mud community hasn't
>> really

> *nod* Distributed servers would be nice, but for 99% of the
> community it's unnecessary.  For a commercial massively multiplayer
> server, I could imagine needing this.  As for capability based
> security, that's my goal... to separate administration from the
> regular player advancement.  I'm sure commercial muds have done this
> through the use of flagging, or extra values, I'm using an int array
> to divide security permissions by function.  Currently using
> Security, Admin, Builder as the dividing lines.

Regarding capabilities:

  http://www.erights.org/elib/capability/index.html

Regarding distributed servers, there are many uses of distributed
servers outside of the land of MMPOG games.  Even within smaller
games. Perhaps -especially- within smaller games. :)

> Clustering would be nice, but I think that's an extention of
> distributed servers.

That depends.  While both are systems that are running on multiple
machines, the design, failure modes, and trade offs are all very
different if you're just distributed over a tightly coupled cluster,
or over a loosely coupled bunch of machines on a LAN, or a loosely
coupled bunch of machines communicating over a WAN.  (But that's not
to say there aren't a lot of similarities, there are.  But the
differences are just as interesting as looking at the differences
between a monolithic server and a cluster-based server or a widely
distributed server.)

  - Bruce

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev