Technical solution to eliminate desync in single-player sessions

Sachiru: The server uses the client's timestamp to generate the delta and mimic the simulation. Latency will not impact that. Seriously, use your head.

"

Note how when I ran my CHEAT in your SYNCHRONIZED CLIENT it WORKED.

You didn't CHEAT anything, you can hack the client as much as you want. The server-side Simulate() function produces output based on the timestamp/seed regardless of what your client does.

In other words, no matter how much you modify the client code, the server will produce output based on the delta/seed.

The server doesn't care if you change the client-side Simulate because the server runs the server-side Simulate.

The only thing you can do is change the packet. And if you change the packet, the server will validate it within the server-side Simulate().

"

The timestamp has to match the action simulation. The server will be able to determine if you hold the packets because it won't produce the same simulation.

I see that you've used the timestamp in the simulation itself, which is interesting. However, the result of the client-side simulation isn't transmitted at any point, so there's no way for the server to know if my (client) version matches yours (server).

In actuality, you wouldn't use the computer's clock, right? The client and server are likely to have disparate clocks (by at least a little). I don't want to be banned because my computer's clock is a bit off. ;)

In fact this sim code smells of a game with discrete states (yes, I know it is anyway) where an update packet is sent every n game-ticks. Why not just model it that way? The use of the UTC clock is adding unnecessary complexity here, especially since it's not really being used outside being an event ordering system. (The "/3" magic number division is the only exception, and I'm not sure what it's actually doing. Should it be "/MoveSpeed"?)

syrioforel: Thank you for the coherent post. Great questions.

"

I see that you've used the timestamp in the simulation itself, which is interesting. However, the result of the client-side simulation isn't transmitted at any point, so there's no way for the server to know if my (client) version matches yours (server).

The client-side simulation doesn't need to be transmitted because each action has a timestamp that the server uses to reproduce the simulation in it's own environment.

"

In actuality, you wouldn't use the computer's clock, right? The client and server are likely to have disparate clocks (by at least a little). I don't want to be banned because my computer's clock is a bit off. ;)

The server uses the client's timestamp/delta so that there are not clock conflicts. The server synchronizes the client's clock when it first connects by telling the client what time to use as the base offset. My code example doesn't really illustrate this.

"

The use of the UTC clock is adding unnecessary complexity here, especially since it's not really being used outside being an event ordering system. (The "/3" magic number division is the only exception, and I'm not sure what it's actually doing. Should it be "/MoveSpeed"?)

It's just being used for initially seeding the time for the first packet delta.

dunno about anyone else, but even if he's wrong about some stuff, i'm still on team qwave lol.

"

The server uses the client's timestamp/delta so that there are not clock conflicts. The server synchronizes the client's clock when it first connects by telling the client what time to use as the base offset. My code example doesn't really illustrate this.

What if my clock has drifted from what's correct, and updates while I'm playing? We shouldn't be using the client's clock for anything. Early in D3, there was an exploit that let you cancel auctions setting forward your computer clock.

Game ticks make more sense in this regard if we want a reliable measure of "game time". It's also easier to enforce that packets are sent every n game-ticks, and you then don't need the deltas.

The only feature such a system lacks is the ability to check to see that I'm not running the simulation "too fast." I expect that's why you've chosen to use an actual clock timestamp. Is that accurate?

"

What if my clock has drifted from what's correct, and updates while I'm playing? We shouldn't be using the client's clock for anything. Early in D3, there was an exploit that let you cancel auctions setting forward your computer clock.

It's not using your Windows clock, it uses your internal processor clock. Even if it drifts, it doesn't effect anything, because the server mimics your clock drift since it uses the timestamps sent from the client.

The key here is: The server replicates the client's exact scenario for validation.

"

qwave wrote:

"

What if my clock has drifted from what's correct, and updates while I'm playing? We shouldn't be using the client's clock for anything. Early in D3, there was an exploit that let you cancel auctions setting forward your computer clock.

It's not using your Windows clock, it uses your internal processor clock. Even if it drifts, it doesn't effect anything, because the server mimics your clock drift since it uses the timestamps sent from the client.

Then

"

// Packet timestamp is not within the required bounds
if (packet.Timestamp > DateTime.UtcNow.Ticks) {
Console.WriteLine("The client's packet is hacked, buffered 'future' packets.");
return;
}

would seem to not properly implement what you describe. The API description for DateTime.UtcNow.Ticks suggests if I set my clock forward, this value would change. There aren't two separate tick counters (one on client, one on server) implemented, so there's no synchronization of clocks as you suggest.

Furthermore, the conditional I quoted above checks to see if the timestamp I transmitted is in the future, and marks the packet as invalid if this is the case. If my packets are an authoritative state as to what the present is (i.e. if the server mimics the clock drift using the timestamps from the client), then this branch will never trigger.

Either way, I think the code on the pastebin is probably not an accurate model of the system you have in mind.

So has anyone actually run his program even once? It's one thing to read the code, and people seem eager to read it and dissect it, and once they get asked to run it, they bail out and say it's trash?

Something fishy is going on here :P If you really want to disprove him, run his code, test if the server notices any change (read: cheat) in the client side, and be done with it?

"

The API description for DateTime.UtcNow.Ticks suggests if I set my clock forward, this value would change. There aren't two separate tick counters (one on client, one on server) implemented, so there's no synchronization of clocks as you suggest.

You're right, like I said, the client wouldn't actually be sending Ticks, it would be using the delta/offset from the server's UtcNow.Ticks. I can update the code if you want, but I was hoping it was implied by some of the comments.

"

Either way, I think the code on the pastebin is probably not an accurate model of the system you have in mind.

The code is designed to demonstrate that the system works. The server can perform a deterministic simulation to validate the client's state.