Technical solution to eliminate desync in single-player sessions

I put my time and money into this game and the desync is constant and almost always unbearable. At this point I kind of wish I would never have picked up this game because it has gotten extremely frustrating to die and not have moved or seen anything until "Resurrect". It is a great game so I keep trying but I wont be recommending it to my friends or playing as much as I would until something is done about this.

TL;DR This game isn't going to the next level unless the Dev's fix constant desyncs.

BudRoaster, im with ya on that. =(

It's not any speed hack - speed hack is another problem.

To be completely honest my method is suffering from other things:
1) Loot coming 5 seconds later -> need to either employ auto-picking or player needs to return for it later
2) Map may not be revealed immediately - this is however questionable whether such thing as partial map reveal will be ever coded into game. There are other problems with it - what to do with desync in time where player is wanting to reveal new part of map.

Those 2 things wouldn't make the game unplayable thou. It wouldn't be entirely pleasant, but still save from death is big advantage.
To note throwing any new random seed to my method of cheating does absolutely nothing, I don't even have to acomodate, will just use new random seed received whenever required! That's not a complication at all!

To note about this system clock hashing - you don't have control about system clock, I have! Will wipe that code from client and use my own clock as I please!

In the absolute sense - you just can check rules you imposed by this method. But YOU DON'T HAVE CONTROL OF THE CLIENT - hacker has! As long as I play by your rules, everything can be mended!
Good bye encryption - I'm one of sides therefore know everything! Good bye system clock - good bye any code in client I won't be liking!

To be even more honest:
1) Would I like to play the game without desync? Absolutely.
2) Would I like to compromise the fairness by allowing that? Absolutely.

I think the only method to fight against these kind of hacks is to employ another thread to periodically scan for client in-memory code changes. With the periodical updates of such code so that it can't be easily disabled. Even this solution is not bullet-proof thou.

Would rather play this in a single player game mode with no ladder and no multiplayer?
That's solution I have proposed, but it was rejected since it would require server code on client -> dangerous for multiplayer modes. With your method single player mode (self-found, no party, no trading) would be possible indeed!

"

To note about this system clock hashing - you don't have control about system clock, I have!

It has nothing to do with your system time. Your timestamp has to match the packet creation time, which has to match the time when the server receives the packet, which is part of the hash to generate the random seed value. Therefore, your snapshot is guaranteed to be in sync.

This idea would not work for one simple reason: Desync

Desync is when your client calculates an outome differently from the server

so.

Under this system, once you finish an instance the server checks to see if it disagree's with your client's outcome... Any time there WOULD have been desync the server will not agree with what your client did and would roll your character back.

If it was possible for the server to review and agree with the client (with no false positives) then we wouldn't have desync in the first place.


All this would do would backload the desync to the end of your run when the server went over the log and it would roll you back.


The real solution would be that in the event of disagreement (desync) the server would give priority to the client's solutions for *some* things and then verify that those solutions do not VASTLY break the rules.

aka your client calculates you moved 10 feet and hit the mob, the Server calculates that you moved 9.9 feet and didn't hit the mob. Server checks and sees that the discrepency is <1% and gives precidence to the client. Boom no desync

demivion: This proposal completely eliminates 'syncing' to begin with. The client CANNOT become out of sync because it sends a snapshot of the actual game 'replay' to the server. The server reviews it at the end of the session. It cannot become 'out of sync'.

It IS possible to do, and it is done by other online games. The white paper I linked describes how to accomplish it, and my original post also describes how to accomplish it.

This thread is expanding so fast I know my post will be buried. But I want to say.

OP, this is genius. Very well thought out and reading the early posts in the thread shows how perfect the system is. A lot of the arguments brought up against you were really bad and not well thought out.

The system could work fine but the chances that GGG will ever do anything like this is unlikely to impossible. Good luck with even getting a response.

Thanks for the support DestroTheGod. =)

You suggest that that enough information be given to the client to allow for the client to fully determine all states. To trust a client with so much information is a gross violation of security. Perhaps for trusted users this would be acceptable. But in a system which is freely accessible to all... very bad idea.

And you expect that the client will return a response which is 'impossible' to fake or alter. Your imagination seems limited if you cannot forsee possibilities for manipulation. It may be difficult, but simply exclaiming it 'impossible' seems naive. Your plan has the client log itself, then gives the burden of validation to the server with data supplied by the client...trusting that the client log is correct. If a server is to trust the information given to it at all, then the security of the system is already broken.
You claim that there is a magical technique utilizing timestamps and hashes which somehow guarantees its accuracy. No such thing exists. Anything generated on a foreign system can also be generated by the foreign system using a different process( and thus allowing manipulation of its results). I give the burden of proof to you.

SkyCore, did you even read any of my post? I'll sum it up based on your response:


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.

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)

3. The server then uses the deterministic seed to validate the full snapshot.


This is a proven software development pattern that is used in countless industries. I even provided a white paper which goes into further detail. What more evidence could you possibly need? What do you need me to elaborate on?

"

To trust a client with so much information is a gross violation of security.

The server validates the client snapshot at the end of the session using the deterministic seed. It does not 'trust' the client.

"

And you expect that the client will return a response which is 'impossible' to fake or alter.

The client streams the snapshot using the deterministic seed that the server can validate. You cannot alter the snapshot without corrupting the deterministic nature of it.

"

You claim that there is a magical technique utilizing timestamps and hashes which somehow guarantees its accuracy.

Yeah, here's some C# code to do it, there's nothing magical about it:

private Guid GetDeterministicSeed(string input)
{
MD5CryptoServiceProvider provider = new MD5CryptoServiceProvider();
byte[] inputBytes = Encoding.Default.GetBytes(input);
byte[] hashBytes = provider.ComputeHash(inputBytes);
Guid hashGuid = new Guid(hashBytes);
return hashGuid;
}

You can then use this to generate the next random number in a deterministic set:

var deterministicSet = new Random(GetDeterministicSeed("foo"));
deterministicSet.Next();


None of this is rocket science, trust me. Most software developers will use techniques like this for basic authentication / security. Every time you log into Path of Exile they are using a similar technique to validate your password.

My solution proposes that you generate the random number using a hash of the seed and timestamp in a packet with each snapshot / action.