[MUD-Dev] TECH: Trusting Network Clients
James Ross Nicoll
jrn at dcs.st-and.ac.uk
Tue Aug 27 13:54:55 CEST 2002
On Tue, 27 Aug 2002, Fox McCloud wrote:
> I lately started planning a graphical MUD and I hope it would work
> so far. But I came across the question to trust the client data or
> not. Of course it would be secure if the server just does
> *everything* but I think this would afford a tremendously server
> power. Well otherwise people could manipulate the data easily, so
> where's the border line, what data should you allow the client to
> process? Any reommendations?
My suggestion would be that the client should interpret the raw
input, and then send the command to the server, while mirroring the
action locally. Let me give you an example:
The user presses the up arrow. The client sends a "user has started
moving forward" instruction to the server, and moves the user
forwards locally aswell. The user then releases the button, the
client sends a "user has stopped moving" instruction to the server.
Next the user decides (lets say) to cast a spell. The client sends a
"user is casting spell foobar" instruction to the server. The server
then sends back any results of calculations, such as damage. The
client then carries out this action.
Its worth noting you can theoretically skip the server having to
send back the results, by having a different random number
generating seed per user, telling the client what it is at the
start, and then if the client and server perform the same
calculations, they should get the same results. However, this leaves
the possibility of the client being hacked to display what the
results of an action would be, without performing the actual action.
Its been suggested this would all involve a significant bandwidth
overhead, however I'm skeptical whether having to tell the server
where the user is, is any less expensive than telling them how
they're moving, for example. Can anyone else give any input on this?
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list