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

[Kwon Ekstrom]

From: "Bruce" <bruce at puremagic.com>
> Kwon Ekstrom wrote:
>> From: "Bruce" <bruce at puremagic.com>
>>>   * 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.

That's also major part of the logging system, those are recorded into
memory as well.

All logs are time stamped during creation, and allow additional data
to be pushed onto them.  Each logging function returns an instance of
log so you can record specific information (to, for example, record
the state of certain variables) Bug logs can accept an exception and
retrieve it's stack trace.

Most of the major events and consistancy checks have logs, I didn't
mean to imply that it was solely for player-admin use.

The ability to attach logs to reports is simply a useful feature for
player administration.  But it'll also help to keep track of data on
bug reports.

> 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.

I have about 8 log channels for various different tasks, each allows a
weight factor, and works with my permissions system to restrict max
viewable weight from admins.

The log channels send to players using the channel code, which stores
a history in order.

>   * 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'd like the ability to do smart searching, and to filter and set
watches using the weight and type.

>> "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. :)

I understand how transactions work, and their uses.  I simply
mentioned that it would be helpful for a distributed server, but it's
not a priority.

That's not to say I've written it out, I've narrowed the data
modification to using functions.  It wouldn't be hard to extend some
objects to being able to handle transactions.


I haven't included the DB section here, but on a side note, I make
backups upon successful load.  If an exception occurs during loading,
then it should attempt to read the backup file.  It's a simple system
to prevent corruption, but it should work.  I wouldn't call it robust
tho.  Nothing incremental or anything.

-- Kwon Ekstrom

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