Technical solution to eliminate desync in single-player sessions

"
qwave wrote:
"
If the server does not run its own simulation in parallel, it has no reference of its own to compare to the client's results. In that case, the "validation" you propose would merely be a rubber-stamp verification of the self-consistency of the data sent by the client. The server would be entirely reliant on the client to report all game results, and would have no way to distinguish between legitimate and hacked results.


Have you even read my posts? The server validates each state hash and updates the in-memory snapshot. It can validate each new state from the saved snapshot. It does not need to run a simulation because the client is doing that on behalf of it. Only when there is a lapse in state hash data does the server begin simulating using the saved snapshot.

The bolded sentence shows where the security issues lie. The only way the client's transmitted results could be "validated" as legitimate would be for the server to reproduce its own simulation of the entire game session and verify that those results were identical to the client's. That would be equivalent to achieving a precise time-shifted open-loop synchronization of client and server simulations, which would be plagued with the same susceptibility to timing discrepancies that real-time synchronization would incur.
Since my field of majoring isn't computer science, I am asking this: your solution won't work for cases where people party with each other, right? Since the game revolves around trading and partying, isn't it then rather pointless to spend so many resources on fixing desync for solo play when that isn't even the focus of the game?
This message was delivered by GGG defence force.
"
The only way the client's transmitted results could be "validated" as legitimate would be for the server to reproduce its own simulation of the entire game session and verify that those results were identical to the client's.


Correct, the server does this by using the snapshot and simulating it against the new state hash. In other words, it's not running the simulation in parallel, but it is comparing two states. It does not need to re-run the full simulation because it is using each state hash to update the snapshot which represents the simulation.



"
you don't know why deterministic random seeds aren't used for what you say they are being used.


Wow. I bet I also don't know why peanuts are used as peanuts.



"
Since the game revolves around trading and partying, isn't it then rather pointless to spend so many resources on fixing desync for solo play when that isn't even the focus of the game?


That's up to GGG to decide. I think fixing desync in solo play is a good start. It especially benefits races.
Last edited by qwave#5074 on Nov 20, 2013, 1:49:08 AM
"
qwave wrote:

That's up to GGG to decide. I think fixing desync in solo play is a good start. It especially benefits races.


Yeah but ur suggestion doesn't do that, as has been explained hundreds of times
Deteego:

I have refuted and provided a detailed explanation on every counter-argument. The most compelling case so far, by Rhys, has been floating point precision. This is a known hurdle, and my recommendation was to simply provide lenience on floating point math in state hashes.

Until he replies, nobody else has provided a compelling case against it. So what do you mean it has been 'explained hundreds of times'? If anything, people have asked me questions, and I have explained the answer.

Rhys would not have replied to this post several times if I was not making a compelling case. We are working towards a common ground which could result in solving desync. Perhaps you should run along and play PoE while the grown men talk.
Last edited by qwave#5074 on Nov 20, 2013, 1:53:46 AM
"
qwave wrote:
Deteego, I have refuted and provided a detailed explanation on every counter-argument. The most compelling case so far, by Rhys, has been floating point precision. This is a known hurdle, and my recommendation was to simply provide lenience on floating point math in state hashes.
"
qwave wrote:
Deteego, I have refuted and provided a detailed explanation on every counter-argument. The most compelling case so far, by Rhys, has been floating point precision. This is a known hurdle, and my recommendation was to simply provide lenience on floating point math in state hashes.


Let me correct that, you think you have refuted everyones argument, the fact that your arguments have detail is irrelevant as to what happens in practice and in reality

I for example, see no evidence whatsoever of the complexity of having to continuously calculate hashes using deterministic seeds and the practical limitations of this, you do realize that they are incredibly expensive to calculate?
"
I for example, see no evidence whatsoever of the complexity of having to continuously calculate hashes using deterministic seeds and the practical limitations of this, you do realize that they are incredibly expensive to calculate?


You can generate billions of values per second, they are extremely cheap. Please stop trying to contribute to a conversation that you literally have no understanding of. How do you think PoE generates random numbers? Fairy magic?
Last edited by qwave#5074 on Nov 20, 2013, 1:57:19 AM
"
qwave wrote:
"
The only way the client's transmitted results could be "validated" as legitimate would be for the server to reproduce its own simulation of the entire game session and verify that those results were identical to the client's.

Correct, the server does this by using the snapshot and simulating it against the new state hash. In other words, it's not running the simulation in parallel, but it is comparing two states. It does not need to re-run the full simulation because it is using each state hash to update the snapshot which represents the simulation.

In that case, the server would be able only to reproduce the potentially hacked simulation results transmitted by the client. So long as the client transmits self-consistent snapshots, the server has no way to distinguish between legitimate and hacked results. As you acknowledged, the server is entirely dependent on the client to run the game simulation on its behalf.
"
qwave wrote:
"
I for example, see no evidence whatsoever of the complexity of having to continuously calculate hashes using deterministic seeds and the practical limitations of this, you do realize that they are incredibly expensive to calculate?


You can generate billions of seeds per second, they are extremely cheap to calculate. Please stop trying to contribute to a conversation that you literally have no understanding of.


Yeah and verifying ontop of that, as well as using a hash that is cryptographically sound. All of this ontop of trying to serve game logic hundreds of thousands of clients in realtime?

Where is your math on this?

Report Forum Post

Report Account:

Report Type

Additional Info