[DGD] Letting the players code stuff

[Noah Gibbs]

  You are correct that all of that is a good idea.  Unfortunately, it will only
solve some of your problems.  You can prevent an infinite recursion that way,
or an infinite iteration, but remember that objects can be created in many
different ways.  Assigning a new hash table to an existing table or array,
entering a new scope and creating new objects can all create more storage space
within a DGD object.  You *cannot* limit the size of a single DGD object, even
though you can limit how they are created.

  So a malevolent player will always be able to create a table containing 100
tables, each containing 100 tables (and so on) and foil what you're doing.  If
he only creates, say, 20 thousand table entries on each iteration then he won't
run out of cycles.  But your MUD will still run out of space very, very
quickly.  There are many related little tricks which DGD's LPC simply cannot
address as-is.  However, by creating an interpreted language *within* DGD you
can fix this problem because then *you* control how player code allocates all
memory, not just some of it.

--- Kurt Nordstrom <kurt at blar.net> wrote:

> Owww.  An interpreted language within an interpreter. 
> Head....hurting...again... ;)
> 
> What about forcing user created objects to follow a certain framework that
> would wrap the active part of their code within an rlimits() framework? 
> The commands given to users could possibly check to make certain that
> their objects are inheriting the correct code with said limitations before
> compilation?
> 
> I need to think this through and come up with some sort of example to make
> sure I'm not talking out of a non-oral orifice here.
> 
> >   This is something I thought about long and hard.  The short answer is
> > that if
> > you don't want players to be able to crash your MUD in some way, you're
> > going
> > to need to create an interpreted language within DGD.
> >
> >   The major concern is resource exhaustion -- you don't want player code
> > to be
> > able to steal all the machine resources and starve the MUD itself.  DGD
> > has
> > excellent protection to prevent this for disk space and processor load,
> > and
> > also does an amazing job with regards to security.  Unfortunately, if
> > you're
> > directly executing LPC code, there's no way to prevent player code from
> > allocating too much RAM and starving your MUD.  To do that, you're going
> > to
> > need to add a layer to check that in some way, which basically means
> > coding an
> > interpreted language.
> >
> >   This language can look exactly like LPC if you want, though you'll need
> > to
> > figure out what the failure mode is when they allocate a new data
> > structure and
> > suddenly their code dies with an error of some kind...
> >
> > --- Kurt Nordstrom <kurt at blar.net> wrote:
> >
> 
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
> 





       
____________________________________________________________________________________Ready for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/