[MUD-Dev] Re: lockless system - foolproof?

J C Lawrence claw at under.engr.sgi.com
Tue Sep 1 11:07:59 New Zealand Standard Time 1998


On Mon, 31 Aug 1998 08:38:35 -0400 
James Wilson<jwilson at rochester.rr.com> wrote:

> On Mon, 31 Aug 1998, J C Lawrence wrote:

>> However such excessively contentious events are easy to detect and
>> guard against.  Here, I (used to) run a little statistics monitor
>> that would note any events that took the game to or near single
>> tasking mode, and if the repeated more than once an hour, would
>> spoof the defining object and freeze the event calls for admin
>> intervention.

> so you've essentially disallowed these contentious-by-nature events,
> right?

Not exactly.  I've disallowed such contentious events which establish
a pattern on bringing the system to single tasking mode.  This is
different from banning super-contentious events.  In the process of
doing this I've also found that many such super-contentious events are
only super-contentious in specific constrained circumstances.  As such
they bring the system to single-tasking mode some times and not
others, with the ratio between the two being in question.

>> That said, much like the old argument of C vs Pascal, free
>> scripting on MUDs is akin to handing chainguns with hair triggers
>> to monkeys.

> heh.

> Seriously, I am reconsidering my own attachment to user scripting,
> in light of this whole threading issue.

I wouldn't consider writing a system without it.  It has massive and
very fundamental impacts on the cultural structure and character of
the game world, as well as allowing levbels of personal involvement
and cause/effect relationships that I don't see are possible
otherwise.

>> Disagreed, strongly.  The reason is actually simple: I find that
>> extremely long running or contentious events are actually of flawed
>> base design.  There is always another divisional structure that
>> allows the same result to be accomplished with less contention
>> points, and often with far greater elegance.

> [example snipped]

> I guess there's two issues here. First, is everything that is
> possible with contentious events possible with equivalent
> non-contentious events? 

I haven't found an exception, but I haven't looked very hard either.
Key however is in defining the item to be accomplished.  Definitions
of synchronicity for instance, eg a SHOUT command for instance that is
guaranteed to deliver its string to all players at the same time, are
unreasonable in such an environ.

> Second, what degree of skill would users need to have to properly
> script non-contentious events?

I haven't found it difficult.  Its mostly just a matter of division.

I have found that its the rare and unusual events which tend to large
working sets.  They happen when people try and accomplish particularly
"clever" or "neat" featuress.  As those are the unusual cases, I have
no problem making them a little more difficult to accomplish.

>> This is the sort of things which I am unwilling to proof against.
>> I'm willing to make the system withstand such onslaughts
>> (monolithinc long running events), which it currently does, but I
>> am not willing to require the system to perform well under such (it
>> doesn't).

> Agreed. As long as a system is powerful enough, it will be
> vulnerable in some sense (if only to resource attacks). I don't
> think there's a way around this, just different sets of tradeoffs.

Bingo.

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




More information about the MUD-Dev mailing list