Technical solution to eliminate desync in single-player sessions

"

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.

I was just checking to see if my interpretation of your code was accurate.

"

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

The client's state would appear to be entirely irrelevant. The only client->server communication is that of the update packets, indicating desired target and some timestamp for when the action occurred.

Provided the client has transmitted accurate data, the client and server states will of course coincide. The client computes state based entirely off information contained in the packet, and the server performs its simulation using precisely that data. Presuming the computation is a deterministic result of the input data, the states will agree.

This is a much weaker claim than that of being able to write a client<->server communication scheme that would be (relatively) desync-free and (relatively) hack-proof.

Desync-free can be easy to show: if no sync is required, a system is certainly desync-free.

However, what is "hack-proof"? The system should somehow be implemented in such a way that it can only be used as intended... whatever that means. Naively you could tabulate a list of common "hacks" (speed-hack, infinite hp, etc.) and thwart them one-by-one. I don't think that's a good idea, though. Your only assurance that your system is secure is that you haven't thought of a way to break it yet.

If I were to make a mathematical claim, I provide a proof. I don't just enumerate what I might consider all of the cases that satisfy the hypotheses and show that the claim is true in each of those cases.

I don't think this code yet demonstrates a resilience of the system against manipulation. The model you've chosen for a game has the property that the data contained in the packets allows one to entirely reconstruct the game state.

Using this simplified model, I could have a client pre-compute an optimal solution consisting of packets that would not be rejected. There is a very specific set of checks that determine if a given sequence of packets is "valid," and these conditions don't have to arise from someone actually playing the game.

I'm sorry for you qwave, you're trying to make your point, but others just refuse to acknowledge it. Well, the thing is it doesn't necessarily have to be made your way, or use your code or whatever. I'm pretty sure the devs are capable of documenting themselves on this matter, we're in the information era after all.

The real and obvious problem is that there is a network problem with the game and they need to fix it, regardless how. The end user has to enjoy playing without noticing these error.

To give a clear example, I introduced a friend of mine to PoE, he really enjoys the game and all, but he keeps telling me that he is "lagging" and "mobs disappear and appear in other places", when in reality it's desync. I don't want to tell him it's the game to not put him off, but I guess he'll figure it out anyway...

"

qwave wrote:

but I was hoping it was implied by some of the comments.

There is no implication in implementation of code. EVERYTHING must be fully explicit. And all these scenarios in which you describe anti-hack methods infer a fundamentally flawed assumption that what the server is validating IS the result of what the client code has generated. As i said 7 dozen pages ago, on my system i am god, i am free to execute any operation or not, to overwrite any bit of data. Any bit of code executed by the poe client and every bit of data generated by it is susceptible to manipulation. All the checks in the world will not be enough to assure the validity of the client output as any checks run by the client can also be run/intercepted/and manipulated by a hacked client. 10 million years in the future, ppl will still not have the ability to do so. It is impossible. There is no getting around this most basic truth. As soon as you trust what the client tells the server security is broken. You cannot trust the client. You cannot trust the client. You cannot trust the client. You cannot trust the client.
It is a different matter to accept vastly lessened security in order to gain the benefits of eliminating desynch in single player gaming. But GGG has previously stated multiple times, they will not do so. This entire thread is pointless as only GGG makes the decision of what to implement.
request thread lock

"

All the checks in the world will not be enough to assure the validity of the client output as any checks run by the client can also be run/intercepted/and manipulated by a hacked client.

Look at the code. The server does not trust ANYTHING the client submits. It validates each and every calculation using the same simulation. I wrote this code so that you would stop making posts like this.

"

However, what is "hack-proof"? The system should somehow be implemented in such a way that it can only be used as intended... whatever that means. Naively you could tabulate a list of common "hacks" (speed-hack, infinite hp, etc.) and thwart them one-by-one. I don't think that's a good idea, though. Your only assurance that your system is secure is that you haven't thought of a way to break it yet.

The client can only submit his actions/timestamp, as long as the server validates this, then it's no different than the way the current server is validating actions. It covers all hacks because all actions are performed server-side, none of them are trusted.

The point im making:
The client is never trusted. All actions are validated by the server.

Wow this thread is going fast. Anyway, qwave, your time stamp signing solution prevents speedhacks, but it's not needed at all. It also does not prevent other hacks, such as arranging player actions in such a a way to get a beneficial result.

Anyway, please everyone forget the qwave's code, it's not needed to detect speedhacks at all.

The simpler way is to make the client send player actions and results of those actions to the server. Then no timestamp signing is needed.

Example:
there's a character at location A, there are two mobs at locations A+10 and A+20.

Character can move at a speed of 20 per second and attack at a speed of 300 ms per attack.

Client sends the commands. Normal case:
at time T from location A attack monster at location A+10. Result - hit a monster for X damage. Then at time T+800ms (500ms to get to A+10 and another 300ms to attack) from location A+10 attack monster at location A+20.

Server runs those same commands at the same time, and sees that the results match, all ok.

Speedhack moovespeed case:

at time T from location A attack monster at location A+10. Result - hit a monster for X damage. Then at time T+400ms (100ms to speedhack to A+10 and another 300ms to attack) from location A+10 attack monster at location A+20.

Server runs the same commands and sees that the client cannot accept that second attack command at time T+400ms, because the character is not done yet attacking the first target. Hack detected.

Attackspeed hack case:

at time T from location A attack monster at location A+10. Result - hit a monster for X damage. Then at time T+600ms (500ms to get to A+10 and another 100ms to hack attack) from location A+10 attack monster at location A+20.

Server runs the same commands and sees that the client cannot accept that second attack command at time T+600ms, because the character is not done yet attacking the first target. Hack detected.

No need to sign anything to detect speedhacks.

"

It also does not prevent other hacks, such as arranging player actions in such a a way to get a beneficial result.

Actions can't be arranged because then you'd have to change the timestamps, which means the server would reject it because it would not simulate it.

"

qwave wrote:

"

All the checks in the world will not be enough to assure the validity of the client output as any checks run by the client can also be run/intercepted/and manipulated by a hacked client.

Look at the code. The server does not trust ANYTHING the client submits. It validates each and every calculation using the same simulation. I wrote this code so that you would stop making posts like this.

The server is attempting to validate client data using logs submitted by the client. But in doing so it assumes the log submitted by the client is correct. This validation could determine poor hacks, yes. But good hacks will fly over the validation process's head. Numerous good hacks have been suggested, there also exists thousands which were not.
What your validation system does do is limit things as to what is possible within the time frame of your frequency of snapshot multiplied by the maximum allowed delay between such snapshots(5 seconds has been thrown around). That is not a 100% guarantee of security.
But all this is moot, it is GGG's decision on what to imp. And they have repeatedly said they would not accept such trade offs.

"

qwave wrote:

"

It also does not prevent other hacks, such as arranging player actions in such a a way to get a beneficial result.

Actions can't be arranged because then you'd have to change the timestamps, which means the server would reject it because it would not simulate it.

Wrong. An automated hack could forge timestamps and be consistent with what the server would accept. You have a lack of imagination.

"

The server is attempting to validate client data using logs submitted by the client. But in doing so it assumes the log submitted by the client is correct.

It validates the same way as the server does now. If you send a movement command to the server, it validates whether it's possible. My system does the exact same thing.

I can't understand how nobody recognizes that the server in my proposal validates stuff in the EXACT same manner as PoE currently does.