[MUD-Dev] Quotes from Marcus Ranum

[J C Lawrence]

For those that don't know, weren't around etc, Marcus Ranum in company
with Andrew Molitor and others was one of the primal figures in the
early days of MUDs and MUD server development.  A great deal of the
current state of the art server-wise derives from work he did or had
his hand in.

It also probably worth knowing that the below started with my looking
for archives to the old Wizards list (thus the reference to the VAX
tapes etc).  "What was the old Wizards list?" I hear you cry in Tom
Leher mockery?  The Wizards list was essentially everything MUD-Dev
is now, just done more than 10 years ago.

--<cut>--

Date: Wed, 24 Jun 1998 22:03:56 -0400
To: J C Lawrence <claw at under.engr.sgi.com>
From: "Marcus J. Ranum" <mjr at nfr.net>
Subject: Re: piqued my interest ... :) 

>Oh yeah, I've been in this game since the early '80's.  Its mostly
>endless rehashes for people who've never been round the merry-go-round
>before.

That's why I got out of it and stopped talking about it. My
C/S and product development experience (at that time) was about
13 years of writing commercial products. I got tired of having
undergrads getting in my face about conjectures when I was dealing
with hard numbers and experimental data (especially regards to
MUD performance and what "could and could not be done")

>> Object migration? :) That was a tough/fun problem -- it'll be neat
>> to see if someone tackles it again. 
>
>So far I'm aware of three approaches out there in the field: yours and
>Stephen's White's (who decided not to migrate, but to RPC objects),

Steve White was Ghondharl, right? He had some good ideas.
Andrew Molitor and I cooked up an even better approach for a
MUD that we felt would scale linearly across processors, using
a real time transaction switching library I wrote ages ago. But
that's another story and all those design notes are lost. If
you ever see references to MDFA (Mud Death From Above) that was
it. :)

>and one chap who claims to be doing a full CORBA wrapper (now
>dissappeared unsurprisingly).  My current model follows Stephen's
>RPC-like model, but one of these days I've been meaning to play with
>object distribution at the base DB level and probably thru a
>stand-alone DB, possibly ala Arjuna.

Interesting approach. RPCs don't historically fare very well on
unpredictable networks (which is why UnterMUD worked the way
it did, including object ghosting).

>> We used some sophisticated stuff in Unter - a complete commit
>> transaction with rollback; Andrew Molitor coded it and I designed
>> it.
>
>This is actually one of the reasons I decided originally to go for a
>fully transactional DB with rollbacks (based on a severely hacked tdbm
>in my case).  I extended it a little by preserving all rollback data
>and thus allowing for effective time-travel via acccesses to stale
>data.  Of course this had the effect of also teaching the bandwidth
>and latency considerations of SCSI RAID...

:)

>> I *MAY* have that stuff on an old DECtape from the MicroVAXII
>> but I can't decode it anymore. 
>
>If so, I *MAY* have a way to read it.  There's a chap with such a boat
>anchor just down the road from me.

Yeah but the problem is *WHICH* tape! I have boxes and boxes
of the damn things. I think I'd rather let that stuff be lost
to posterity. :)

>> How amusing to see people angsting about MUD performance...
>
>Some of them have good reasons.  They're attempting to do full world
>simulations with very code-heavy objects.  When you have a basic DB
>with several hundred thousand active objects the working set tends to
>become both large and unwieldily fluid.

Did any of them ever look at the extremely subtle difference
between the object caching policy in Unter versus Uber? Unter
was nearly 10 *TIMES* faster than Uber, in terms of how much
CPU/memory bandwidth it used, because of the way objects
clustered in the cache. (Uber was really just a test case I
wrote so I could get some measurements on a real system so that
when I wrote another MUD I'd know what I was doing) :)

>> when I was running a 100,000+object database with 50 users on a
>> MicroVAXII with 8MB of RAM...  :)
>
>The last time I had a running server (ie before the last gut), my test
>world had approximately 12 million objects of which around 800K were
>"active" (ie capable of originating an event without external
>stimulus, the classical case being mobiles, the more typical case
>being more mundanely animated and light weight objects).  Being a test
>world, the majority of the active objects truly were active,
>originating new events at an average rate of one every 15 seconds per
>object.

Holy shit.

There are reasons why games like DOOM do line of sight
activation. :)
Andrew and I once coded a world in Uber where there were
monsters and it'd do a delta time on the monster since it
"went to sleep" and allocate a load of actions for it to
take immediately on wakeup... Worked good. :)

Yeah, tho - I read about the kind of stuff (especially scaling
problems) that games like Ultima Online have and I have to
cry. The architecture of MDFA would have easily supported
the kind of thing they're doing. <<sigh>>

>My working set, given about a 12Meg DB cache, was just over
>28Meg as I recall (been a while).  A big part of the problem of course
>was that the internal format for objects is (currently) very space
>heavy for me (soft-code, byte-coded and flat versions, plus state
>data) and I often maintain multiple copies of the same object in
>memory prior to commit resolution...

Yeah, for readability you gotta tag the code with the object,
I learned that too late in Uber.

What I planned for MDFA was to actually generate a builtin
API in C. The core universe routines would be compiled into
the server. Object routines would be compiled into .o files
and dynamically loaded into a server agent that would generate
raw database calls -- a separate process -- against a dataserver
that shared a memory space with it. Sophisticated shit.

I canned the project when I had a lot of $$$$$-making work
come my way and decided I would rather have $$$$$ than
impress a lot of CS undergrads. :)

>No users of course, but the resource drain was noticable.  Note also
>that I'm not using the room model, but going for a free coordinate
>system.

Ouch.
Andrew did a free coordinate version of a MUD universe in
UberMUD. It did a recursive search (happened to work great
with the underlying B+tree of UberMUD) to determine relative
locations.

>Other notes: 
>
>  UOL averages around 2,500 users per shard.  I have no stats on the
>object count per shard.  They're running on Linux boxes last I
>checked.

Hm, that's better than I thought. I wonder how the engine works -
is the transaction consistency centralized or serialized? I wonder
if the guys who wrote it actually knew anything about high speed
non-consistent transaction databases.

>  Nathan Yospe's model (which has been partially admpted by a few
>others) is compute heavy as he dynamically simulates fragments of the
>world by computing its current state by extrapolation from the last
>time it was fully generated (almost no fixed data definitions, only
>fixed formulae and an axiomatic base of laws of physics).

How has it worked out in practice?

>> Take care, mjr.  -- Marcus J. Ranum, CEO, Network Flight Recorder,
>> Inc.  work - http://www.nfr.net home - http://www.clark.net/pub/mjr
>
>I had a poke about your gallery.  Nice.  I particularly liked your
>comments on how to handle models.  Very much along my own ideas on the 
>area.  <bow>

You a photographer?

mjr.
- --
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr

--<cut>--

And a quick follow-up to the same:

--<cut>--

Date: Fri, 26 Jun 1998 09:53:08 -0400
To: J C Lawrence <claw at under.engr.sgi.com>
From: "Marcus J. Ranum" <mjr at nfr.net>
Subject: Re: piqued my interest ... :)

At 02:50 PM 6/25/98 -0700, you wrote:

>Marcus,
>
>Would you mind if I forwarded the below to MUD-Dev?  I expect they'd
>be interested.

Suuure. :)

You might also be amused to know that the byte-interpreter from
UberMUD is (much mutated) at the core of our product, the Network
Flight Recorder (www.nfr.net)  :)

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr

--<cut>--

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...