Technical solution to eliminate desync in single-player sessions

I read your white paper, and it was shit.



Now that's what I call low standards.

Even from the context of only caring about speed-hack, that isn't proof of invulnerability, that's proof of ensuring the average speed is the legal speed. Synchronization is not continuous, it is discrete; therefore, although there is a distance cap between syncs, there is not a speed cap between syncs. All a hacker would need to do (after a few banned accounts through trial and error) is use Wireshark, determine synchronization packet signatures, and ensure that maximum distance never exceeded the allowed threshold; this would be partially limiting, but things like being idle for 0.9 seconds then moving ten times the normal speed for 0.1 seconds would work just fine. With the hack controlling output, even idle for 0.99 seconds and moving at a hundred times normal speed for 0.01 seconds is possible, if the player happens to click during that extremely small time window.

Also, I'm honestly surprised the author(s) don't bring up movement skills. At all.

But even the authors of the paper don't really pretend that what they are discussing is significantly complicated than simply verifying player position against a common-sense rule: velocity x time = distance. (It's is a white paper, so it does make things all academic and formal, but they're not pretending the core idea is actually complicated.) It doesn't advocate sending a full replay to the server every second, because that's simply not feasible; the bandwidth requirements would be too extreme. The paper has enough common sense to cover what happens when communication is lost on its way to the server; OP takes it for granted and acts like the server will not be desynced itself (sure, the client wouldn't be, but the server would be, often).

All methods like this would do is ensure some combination of actions, over a short period of time, would have to add up to some particular sum, and would still be at least somewhat vulnerable to communication-denial hacks which prolong that short period of time by deliberately desyncing the server. Within that window, hacks would still be fully in control, able to assign whichever values they desired to whichever events and maintaining a slightly more beneficial mode for the hacker — perhaps not god mode, but substantial enough, especially if unique drops are involved in any way.

You could up synchronization attempts by having the client check with the server more often, but that just brings us back to square one: the more the server has to sync to verify the client is not cheating, the more synchronization traffic GGG has, and the more prone to desync the overall system becomes.

This idea is still horrible.

"

qwave wrote:

2. During play, the client streams the snapshot progress in realtime to the server. The server does not need to validate the accuracy of the snapshot until the session 'ends' (The client disconnects, TPs, leaves the instance, etc)

Although the concept of streaming is indeed more continuous (and not in the white paper, by the way), which gives it an advantage over discrete... and actually probably would work... are you really counting on a client computer to be able to stream a massive amount of UDP data continuously to the server? That's a lot of uploading, when most internet connections are set up for downloading. Not only would this be the GGG server equivalent of watching tens of thousands of YouTube videos simultaneously, but I doubt the average client's internet connection could reliably handle it.

And, more to the point, you're talking about attempts to remove desync. Why is it that all of your alleged solutions all involve even more traffic between client and server than there is now?

The simple fact of the matter is: there is no method you can think of which both solves security issues and has less net network traffic than simply keeping things on the server. I'm not saying you can make client-centric gaming secure, but I am saying that you can't do it with less bandwidth than simply keeping things server-side and having the server stream the data to the client... instead of the other damn way around, which describes precisely what you're trying to do here.

Scrotie:

You can already currently do these things in Path of Exile. You can 'speed hack' during the period of latency since your last packet based on movement speed. The server will validate it and not desync you. Every MMORPG works this way. The paper was describing basic position prediction against latency.

"

It doesn't advocate sending a full replay to the server every second, because that's simply not feasible; the bandwidth requirements would be too extreme.

I never suggested 'sending a full replay to the server every second'. In fact, the client will be sending the same amount of data that it is currently sending. The snapshots will only include the actions that the player is taking. I use the term 'snapshot' because the client can package the data and send it less frequently than it currently is. I still expect each snapshot update to be under a kilobyte.

"

Within that window, hacks would still be fully in control, able to assign whichever values they desired to whichever events and maintaining a slightly more beneficial mode for the hacker

No, you cannot modify the events without corrupting the deterministic seed and game time. Hacks of this nature are not possible. Moreover, the server would be responsible for generating item drops.

"

qwave wrote:

Scrotie:

You can already currently do these things in Path of Exile. You can 'speed hack' during the period of latency since your last packet based on movement speed. The server will validate it and not desync you. Every MMORPG works this way.

Here's my solution to that:

The server doesn't give a fuck about what the client says its position is. The only thing it cares about is:
command to move to (x,y) received at time z.
Notice I didn't say a damn thing about when the command was sent, because server doesn't give a fuck. And then the server moves the character, and streams the client where he or she is. And none of that "reporting your position" nonsense matters. At all.

@qwave

i do not understand why the entire 'snapshot' (do you mean the game status?) should be sent to the server. As long as the client knows all the games rules, it would suffice to stream the client timestamped commands to the server (it requires far less data, and can also be delayed a few seconds). Furthermore, by sending all info, you would have bandwidth problems, since with 10K+ players you will saturate the server input bandwidth (it is the same issue as desync, but reversed). Also you would need the server to store each snapshot (it requires ram and cpu).

The server should simply check that each command of the client is legit.

In what i have in mind, the server stream also a new rng-seed each x seconds: this does not allow the client to calculate the entire session, and it force some sort of sync by requiring the client to be connected to update the seed.

Another suggestion: to scramble things each new hash could be calculated as a function not only of the previous one, but also of the current gamestatus.

Hellgauss, you are correct. 'Snapshot' is just the term I use for the next 'chunk' of data. These will be slightly larger than traditional packets because they will contain a bundle of input data over the last second.

Scrotie: That's probably how it's currently done.

"

qwave wrote:

"

It doesn't advocate sending a full replay to the server every second, because that's simply not feasible; the bandwidth requirements would be too extreme.

I never suggested 'sending a full replay to the server every second'. In fact, the client will be sending the same amount of data that it is currently sending. The snapshots will only include the actions that the player is taking. I use the term 'snapshot' because the client can package the data and send it less frequently than it currently is. I still expect each snapshot update to be under a kilobyte.

"

qwave wrote:

1. The client receives a deterministic seed from the server in order to generate the snapshot. This seed allows the server to validate that the snapshot follows all the rules of the game.

In before some quibble about how "snapshot that follows all rules of the game" doesn't mean "full replay."

Also: you mean the same "under a kilobyte" that GGG is currently having desync problem with? I posted some stats earlier, and IIRC, average traffic per second was just under 2KB. Not that high; more than the current desync situation can handle.

"

qwave wrote:

"

Within that window, hacks would still be fully in control, able to assign whichever values they desired to whichever events and maintaining a slightly more beneficial mode for the hacker

No, you cannot modify the events without corrupting the deterministic seed and game time. Hacks of this nature are not possible. Moreover, the server would be responsible for generating item drops.

Like I said earlier, all a hack needs to do to improve the game experience is to take two or more similar situations, which would both occur within the same sync gap, and say they occurred in the opposite order, applying the next numbers in the random seed to one, and one to the other. Given timeframe, this might be difficult to eek out a large advantage, but the cumulated effects of such good luck would eventually be noticeable. Outside of up-streaming, you haven't listed a single method which would secure against this, and UDP down-streaming is a much better alternative to up-streaming.

Didn't read through all 27 pages of posts so not sure if this has been mentioned, but one cheat / hack that immediately comes to mind that you didn't address is map hacking (i.e. display the layout and location of all mobs)

Since map hacking doesn't change anything about the instance being played, the mechanism to catch cheating won't work. Obviously this is not nearly as big of a deal as say duping items, but it is still a cheat in that it allows a player to play any given instance optimally and thus save quite a bit of time exploring the map. If you were running a Mazed map with Temp Chains or something this could actually save 15-20 minutes easily.

"

I posted some stats earlier, and IIRC, average traffic per second was just under 2KB.

This is probably because there are many packets being sent during that second. The snapshot would combine those packets into a single packet, which would significantly reduce the overhead.

"

Like I said earlier, all a hack needs to do to improve the game experience is to take two or more similar situations, which would both occur within the same sync gap

You still don't seem to understand. Before you even have time to 'change your mind' and perform a different action, the game will have already rolled a new seed 10 times. Actions that you perform are going to take at least 500 milliseconds, and in that time the seed is going to be rerolling. A bot is not going to be able to compute the seeds quickly enough without crashing the game.

"

one cheat / hack that immediately comes to mind that you didn't address is map hacking

The server can store the mobs/map on it. The client only needs to be initially trusted for things that cause desync, such as pathing/combat actions. So map hack would not be possible.