[MUD-Dev] Gearing up against GEAR

Sean Kelly sean at ffwd.cx
Sun Jul 22 18:00:41 New Zealand Standard Time 2001

From: "Vincent Archer" <archer at frmug.org>

> According to Dan MacDonald:

>> Here's a link to Dr.Twisters Gear page. Apparently it works for
>> other Games as well, essentially what it does is multiply the
>> packets sent By the client up to 256 times, confusing the server.

> That's a slight misunderstanding. It does not multiply packets,
> per se (if it duplicated packets, nothing special would
> happen). As Ted originally postulated, Gear mucks your internal
> windows timers, fooling the client into thinking that a second has
> elapsed when a fraction (or multiple) has in fact elapsed.

> So the client think it's running at 15 FPS instead of 30, and
> speeds up all animations and action timers by the same factor.

> 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 don't buy this.  AC, like MMORPG's, will repeat the same combat
action until you explicitly alter it.  So when I hot "attack
fast/weak" I continue to attack fast until I press the "attack
slow/strong" button.  So the client isn't sending "attack" commands
every few ticks, it's telling the server "i'm going to keep
attacking at this rate until further notice."  The server then does
realtime turn-based resolution of combat based on its own internal
timer.  Issuing multiple attack requests is meaningless.

For spellcasting, there might be a slight advantage is using GEAR.
As while spells take a fixed amount of time on the server, they are
one-off events.  So in times of high lag it might pay to push
through a couple spellcasting packets all at once.

> I'm surprised accelerated movement from GEAR works, given that,
> for AC the server *does* process movement and has to acknowledge
> it.

I agree.  All I can see GEAR doing for AC is screwing up the
framerate on the client side and flooding the server with extra
packets on the server side.

> How does one fight GEAR? I see no solution except to report the
> timer on the client in the packet protocol. This allows the server
> to check for time drift. If time drifts constantly and at a fast
> rate, the client is probably GEARed.

Is there a way to get at any other timer that isn't affected by
GEAR?  If so, I'd report both.  Drift should be rapidly obvious.


MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list