[MUD-Dev] Gearing up against GEAR
Travis Nixon
tnixon at avalanchesoftware.com
Sun Jul 22 16:31:01 CEST 2001
From: "Vincent Archer" <archer at frmug.org>
> Now, you'd say, why would the server trust the client on such a
> matter? Well, given that combat actions have a timing that is
> smaller than the tolerable ping over Internet, there's no way the
> AC server can validate *all* actions from the client and
> acknowledge them, like this:
> [Client tells STRIKE] -> [Server reports STRIKE allowed again now]
> I'm surprised accelerated movement from GEAR works, given that,
> for AC the server *does* process movement and has to acknowledge
> it.
But this is the point exactly. If you let the client choose what to
do, you HAVE to validate its actions. If you don't validate all of
its actions then you are trusting it, which we all know is bad. So
the server does indeed need to make sure the strike is allowed.
However, there's no reason for the client to ask if it can strike,
and wait for a server response before doing it. The client checks
its time since the last strike, and sees if it can go again. If so,
it does. It doesn't need to ask the server. It needs to TELL the
server, but not ask.
Then the server checks that everything it's being told is in fact
possible, and only updates state on possible actions, while flagging
impossible ones for review.
You know what, though...the simplest way to do time-based validation
would be by basing times on client-side timestamps, and that's
exactly the sort of thing that's susceptible to something like GEAR
that speeds up the clock. So I guess what you have to end up doing
is doing some sort of average over time, because transmit times are
not constant. Of course, then you run into possible problems like a
client who strikes double speed for half the battle, wounding their
opponent into near uselessness, and then strikes half-speed for the
rest to finish them off.
Ugh.
Now we're moving from the area of averaging into the area of
backtracking to see what the earliest point you could possibly
receieve a new strike. So from a client who should be striking
every 5 seconds, it's entirely possible that you receive a strike at
9 and a strike at 10. That's a valid exchange even though there's
only one second in between the strikes. But receiving one at 6 and
one at 7 would not be valid, because the internet can only slow
things down, not send them back into the past. :) This is where
things start to get pretty ugly, but hey, I didn't say validation
was easy, just that you have to do it if you want to prevent
hack-based advantages.
Anyway, GEAR simply shows the scope of the statement "Never trust
the client", because with GEAR, you can't even trust the client to
tell you that there are 60 seconds in a minute. :)
_______________________________________________
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