Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

"

Couldn't you (the player) simply introduce an artifical delay between actions on the client and sending the info to the server? At the very least this could be exploited to prevent deaths in hardcore.

Let's assume someone had the ability to do this dependably. So what you're suggesting is that I am playing hardcore, and a mob kills me. However, since my client is authoritative, I can simply 'roll myself back' before this death and not actually notify the server that I died.

There are two considerations I would make in this situation:


1. You could only roll yourself back as far as the last snapshot data you streamed. The client will be continually streaming your snapshot in realtime.

2. The server must mandate that it receives a continuous stream of data, otherwise it will forcefully sync you back to the last known state. You might consider this the same thing as the 'desyncs' that we already have. However, this particular 'desync' has nothing to do with being out of 'sync' as much as it has to do with an actual 'loss of connection' (The actual data stream connection has been severed). This would not occur nearly as frequently as the current desync.

"

If the client computes all combat actions and then sends them back to the server (which then validates them), then the client data must include a log of the death activity. If the death activity can be isolated on the client, then a program can be designed to actively monitor the logs. This program needs only actively search for this indicator, and replace the death action with a logoff action. This could be done within hundredths of a second with virtually no character rollback.

"

syrioforel wrote:

That depends on how many things you allow to modify the RNG state, how often your updates need to be sent up to the server (needs to be properly addressed still), etc.

"

qwave wrote:

Scrotie, I appreciate your criticism, but you still have a misunderstanding on how this 'pool of numbers' is used. Lets assume your pool of numbers are:
0.52, 0.1, 0.9, 0.33

This means that you would have to fabricate a situation in which these randomly generated numbers are used to generate random numbers in your favor.

"

ScrotieMcB wrote:

"

qwave wrote:

There is not a 'pool of random numbers', its a deterministic seed. You are misunderstanding the nature of how this works.

Bullshit. It is a pool of numbers.

Deterministic seed #XXXXXXX = RandomNumber1, RandomNumber2, RandomNumber3, RandomNumber4, ...

When you have a seed, a deterministic random number generator is no longer truly random, it's deterministic. It's a specific set of numbers, and when the client can order events, it's a pool of numbers which can be ordered as it wishes so long as it knows the seed in advance.

Just in case you didn't know this already, GGG already sends the client a random seed for the map layout of an instance. So guess what? We have fully functioning maphacks in the game right now. That is just what happens when you give seeds to the client.

"

The internet is by nature erratic - you can easily delay sending data to the server for several seconds ("lag spike") in order to massage the data as you see fit, and the server can do nothing about it because many clients will do exactly that normally without any malicious intervention.

"

You can augment a PRNG to have the internal state (which is initially the seed) modified by actions that don't use random rolls, so that the sequence of rolls that appears depends also on the actions performed by the player.

That can also be a bad thing.

"

Tuoweit wrote:

"

syrioforel wrote:

That depends on how many things you allow to modify the RNG state, how often your updates need to be sent up to the server (needs to be properly addressed still), etc.

The internet is by nature erratic - you can easily delay sending data to the server for several seconds ("lag spike") in order to massage the data as you see fit, and the server can do nothing about it because many clients will do exactly that normally without any malicious intervention.

"

Yeah, that's definitely a problem. If you allow 5s of delay between action and uploaded event, you can brute-force-search the best (5s-actual_latency) of play possible, and then upload that instead.

"

qwave wrote:

"

If the client computes all combat actions and then sends them back to the server (which then validates them), then the client data must include a log of the death activity. If the death activity can be isolated on the client, then a program can be designed to actively monitor the logs. This program needs only actively search for this indicator, and replace the death action with a logoff action. This could be done within hundredths of a second with virtually no character rollback.

The server could simply introduce a 5 second log-out requirement.