[MUD-Dev] distributed objects

Brandon J. Rickman dr.k at pc4.zennet.com
Mon Feb 14 21:36:32 New Zealand Daylight Time 2000

On Mon, 14 Feb 2000, Vijay Weasel Prabhakar wrote:
> 	If I understand you correctly, which I may not be doing :), you
> want to get rid of some of the server's work and distribute it to the
> players?  This problem is one into which I've put a lot of thought.  I've
> realized that only trivial tasks can really be given to the player.
> Anything that is at all important increases the abuse potential
> tremendously.  Of course, it takes a sophisticated player to pull it off,
> [and similar stuff in this thread inevitably leading to "never trust
>  the client"]

I've always been bothered by the "never trust the client" law.  It is
misleading: it says you can't trust an _individual_ client, but people
interpret this as "you can't trust clients in general".  Shouldn't one be
able to devise a robust distributed network across several clients, such
that errors (or cheats) on one client will be detected when compared
against other client results?

In other words, ask the client run by player A to compute the results of
one round of combat.  But also compute that same round of combat on two
(or more) other clients.  So you've got a redundant system.  If player A's
version is wildly different from the other two, assume that she has a
hacked client and dump her from the game.  Similarly, if player A's
calculation agrees with player B's calculation but not player C, then C is

Of course now the server will have to send out more data for each
transaction, and make all the decisions about which clients to trust, in
addition to maintaining the game world.

So if someone does hack a client, they have to know who the redundant
clients are _for that particular calculation_, and hack those clients as
well.  The odds are against the same version of a hacked client being used
by all the redundant clients.

If you had such a system working, you could then gradually grant more
trust to particularly trustworthy clients.  Not only is the client holding
the trusted data for the character, it is trusted with the player's
weapon, armor, inventory, &c.  Lest a cleverly hacked client try to take
advantage of this, you still perform spot checks on those objects.  When
the client is ready to log out, it sends all the trusted data back to the
sever, but if there is anything fishy in the data then the server will
dump that data and revert to the redundant data.

There is still a way to locally abuse the system: build up trust for your
client, then take advantage of that trust to boost your
character/weapons/&c.  You can then wreak havoc until the server catches
on, but in the meantime you have killed all the rabbits and what not.
But then again, you'd want to be doing spot checks on the occasional
combat round.  (If you make it so that the client has no information about
what the objects are that it is operating on, so that it can't say "Ah,
this object is my character, so I'll give it a boost", then if the client
tries something funny, there is no guarantee that it will help that
client's player.)

- B!
(moved to dr.k at zennet.com, for those keeping score)

MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list