[MUD-Dev] distributed objects

[cjones at one.net]

On 14 Feb, Kevin Littlejohn wrote:

<!--snip-->

Caveat: I'm approaching this from the standpoint of a Java
programmer...that includes Java Remote Method Invocation (RMI) which
establishes an object's methods that can be called via a Java Interface.

>   ------------------------------------------------------------------------
> 
> (Ramble about caps and object trustworthiness)
> 
> Ok, we were discussing the other day the whole 'objects interrelating' thing.
> My original thought was that each object was an entity unto itself - the "pure"
> object view, where nothing is changed in an object except by asking the
> object to change it, and each object itself is master of it's own domain.
> Interestingly enough, that's the first precept of the writings at
> www.erights.org, regarding caps systems over distributed objects.
> 
> Phil's comment on that was that it's impossible to construct a decent fight
> system, for instance, under that setup, because you can never guarantee that
> an object has actually decremented it's hit points when it's been asked to.
> The solution he had to this was a 'mediator' setup, tied into the caps system,
> which I kinda like.  Basically as follows:
> 
> 1) We have caps over various ops on various attributes of objects.  In the caps
> world, this means we make a 'key', that says 'whoever holds this key can change
> my hit points'.
> 
> 2) We have objects talking to each other, if they want to let others change
> their hit points, they hand them the key.  All well and good to here.  The
> degenerate case is that every object has the 'set' keys to it's own attributes,
> and 'get' keys for all other object's attributes.
> 
> 3) Now we introduce mediators.  These would define a context of 'being' -
> to join that context, you'd have to satisfy the mediator's conditions.  Those
> conditions would be expressed in terms of keys - the mediator would say 'to
> participate in this context, you're going to have to give me the key to set
> your hitpoints, and drop it yourself.'  If an object chooses not to participate,
> it's effectively ignored, and cannot use the facilities provided by that
> mediator/context.  If it chooses to participate, it hands over the keys to
> its hitpoints, and can no longer set them itself.
> 
> This seems like a neat idea - it allows us to move the world mechanics
> completely into the world itself (no comments about defining a system
> within the system being impossible, please ;).

By making all the object properties public, then you can perform
verification that is assured to be accurate--it's not necessarily the
object's methods returning the property value, but the machine itself.

However, you still want to perform setter operations through the
mechanics provided by the object. In that way, the object can perform
housekeeping as certain conditions occur:

- it's not the caller's job to know that the object has just died or
  entered some other state (mortally wounded, bleeding, etc.)
- it's not the caller's job to know that the object is immortal or
  invulnerable, such that no damage can occur to the object, or that the
  object can assume damage, but can never enter the dead state
- it makes world mechanics so much easier to assume that the object is
  the authority, so that healing or other external manipulations can
  take place by notifying the single object, not broadcasting for the
  last caller who may hold the lock. (This is one of the things I like
  least about the caps/key system--even if the lock is published on a
  global data structure, you can run into race conditions.)

All objects that implement that 'Attackable' interface, for example,
know how to BE attacked. It's the individual object's implementation
that varies, though most will pass the attack call to a utility class
(which acts as a mediator, though this can be bypassed). In this way,
you can make sure that certain objects like doors, windows, or equipment
that can be damaged or destroyed don't require special methods to assume
that damage. Specialized classes like NPCs can capture relevant
information about the attacker and use it for hate lists, notifications
to allies, etc.

But no, there's nothing to prevent the objects from lying about their
state. The assumption is, even with remote classes and objects being
loaded into the machine, that all objects follow the contract put forth
in the Interfaces (that a PC (superclass to NPC and Player) will always
implement Attackable) and that the implementation is correct.


> I was thinking further about this today, after running across
> http://home.devlocus.org/psion/prog/manifesto.html - someone's 3D distributed
> object engine.  The major flaw in the above is that this all relies on some
> way of verifying that the object is actually telling the truth about having
> reliquished the keys.  We can guarantee that's so in our current case,
> because we control the object data, but should we be paying some thought to
> the idea of distributing the objects themselves - data and all?  How would you
> guarantee that a remote object is behaving the way it claims to be behaving?
> Is this the same problem EverQuest et al face with clients that have too
> much information, and is there a solution?  If there isn't, does that mean
> that multi-user games are ever and anon going to have to store all data
> server-side, and perform all manipulations there likewise?

I would tend to consider that trust in those objects would only come
when the objects originate from a trusted server. Objects are signed as
they pass enter the network. The signature is used to verify the origin,
with each server using a server key that is registered with the
destination server. Bad code could only enter the trust network if a
trusted host acts to relay and resign the classes, rather than indicate
that the classes should be loaded from the untrusted host. You can do 
the same thing with clients that keep part of the state of the
world--only do business with those that already have that relationship
(signature) established.

Please note that because of my Java heritage, I'm not worried about
execution of bad RMI code on my server from some other server. The code
will actually execute against the data on that other server, on that
other server's VM. I'm waiting for a reply to my method calls, and if
the other server has poorly written code that consumes all of its VM,
it's not my problem--I just need to catch those exceptions and provide
for timeouts. My VM keeps on trucking.

Alternatively, if you design your own VM that doesn't perform RMI, you
can perform verification of the class methods as they enter your system
and check them for correctness. I think it's just easier, however, to
designate which servers you trust.


> One alternative would be to enforce the keys thing above by migrating
> object data to the server where the object relinquishes control over it - so
> in the degenerate case, all objects carry their own data, but when they
> choose to participate in a context, they relinquish control of their data
> not only by handing the keys over, but by handing the data over as well.  This
> has synchronisation issues, especially if the object is being used on
> multiple different services (thinks sideways toward the idea of a single
> avatar for multiple games, grins, carries on), but that might be an easier
> to address issue than trust of remote objects...

This whole message sounds a lot like some of the issues they've had with
the GPLed Quake, recently, except that you don't play multiple games at
once.

> Rambling,
> KevinL

Chris Jones






_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev