[MUD-Dev] distributed objects

[Vijay Weasel Prabhakar]

On Mon, 14 Feb 2000, Brandon J. Rickman wrote:

> On Mon, 14 Feb 2000, Vijay Weasel Prabhakar wrote:
> 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
> untrustworthy.

	Not really, at least not in a combat system.  You can't tell what
a random number is going to be unless you provide the seed, so it's tough
to say that two rounds of combat are going to turn out the same way on two
different clients.  

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

	I think the eventual objective is to reduce the requirements on
the server's side by pushing work off to the clients.  The redundancy will
really go against this objective.  You might as well be doing everything
on the server side.  I think you could always figure out that your object
is yourself.  It wouldn't take too much looking to be able to identify a
few traits that establish your identity and then search for those traits.
Random spot checks would not really work unless you were keeping up with
the client constantly in which case you're doing as much work as you were
before.  

	Correct me if I'm wrong here but the objective is to reduce the
amount of work and resources used by the server, right?

-Vijay





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