Technical solution to eliminate desync in single-player sessions

I haven't read the whole thread, because it's just too much to read XD.

But when it comes to desync and a possible fix I would say the best way to do it is resyncing the player and the mobs on screen every 500ms by default. Basically what "/oos" does.

If the positions are stored in double variables they have 8 bytes.

Let's assume there is X and Z coordinates
( I don't really see the need of an additional Y coordinate ):

8 bytes * 2 = 16 bytes

Let's assume there are 100 mobs on screen:

8 Bytes * 202 = 3232 Bytes
3232 Bytes ~ 3.15 KB

And if the positions are resynced every 500 ms:

3.15 KB * 2 ~ 6.3 KB

So if the server would resync the player and all mobs on screen every 500ms it would have to send ~6.3 KB to the client per second if there are actually 100 mobs on screen.
Usually there aren't 100 mobs on screen though.

Now I have to admit: I don't know what upload speed a typical game server has.
Also I don't know what the server is actually sending atm.
But to this point 6.3 KB per second for each client doesn't seem too impossible.

I'm not a network expert, so maybe I'm missing an important point here, but why is that not a solution?

I'm talking about positions only.

EDIT:

And if that is eating too much bandwidth if many players are playing it could also be done for the player only.
That would already help a lot I guess.

Ok, that way it won't save you from desynced mobs.
But it would save you from desyncing yourself and silently running in a room full of mobs whhen you just wanted to attack a single mob outside the room.
Last edited by grasmann#3903 on Nov 23, 2013, 5:20:50 PM
Im with you guys. I can see a secondary channel streaming through udp. Security concerns over this can be largely dismissed.
For years i searched for deep truths. A thousand revelations. At the very edge...the ability to think itself dissolves away.Thinking in human language is the problem. Any separation from 'the whole truth' is incomplete.My incomplete concepts may add to your 'whole truth', accept it or think about it
Last edited by SkyCore#2413 on Nov 23, 2013, 5:47:18 PM
"
ScrotieMcB wrote:
I probably shouldn't post this, but it is relevant to the discussion.

There are actually methods to get a remote server to trust the client; this process is known as trusted computing, and involves computers being outfitted with a chip (hardware) called a TPM which stores a private encryption key which it then hides from the user and the rest of the operating system, using a process called curtained memory to perform encryption and decryption tasks without allowing the operating system to view the key in memory. The processor can call on the TPM to encrypt something, but decrypting the key based off the results is essentially like deciphering a giant hash that would take decades (if not longer) to break.


The hardware-based implementation of currying is not too important here unless the entire OS is built around this and doesn't let you load kernel modules that aren't signed and none of the kernel modules have exploits. Only one of those is true. Remote attestation seems to be done only on windows preboot log so I don't think that's much of an issue here.
"
ScrotieMcB wrote:
I probably shouldn't post this, but it is relevant to the discussion.

There are actually methods to get a remote server to trust the client; this process is known as trusted computing, and involves computers being outfitted with a chip (hardware) called a TPM which stores a private encryption key which it then hides from the user and the rest of the operating system, using a process called curtained memory to perform encryption and decryption tasks without allowing the operating system to view the key in memory. The processor can call on the TPM to encrypt something, but decrypting the key based off the results is essentially like deciphering a giant hash that would take decades (if not longer) to break.

However, the cost of the server being able to trust the client is that the client can be made far more dependent on third parties. For example, music files can be sent encrypted using the TPM private key (or a derivative), which means such files cannot be easily pirated; however, this essentially means the user has data encrypted on their hard drives which they do not have the key for. TPMs in general give more power to those who make TPMs (and those who do business with them), leading to an Internet where the user has less and less control over their own data. Imagine a future where OpenOffice no longer works on MS Word documents, because MS Word encrypts saved files using the TPM.

When I worked in the US Army, we used TPMs quite a bit, but I considered such use ethical, because at the end of the day the Army controlled the private keys hidden in the TPMs, and the users did not own the systems — the Army did. In instances where the holder of the keys is also the owner of the hardware, obscuring private keys within TPMs is ethical.

Applying TPMs to general public computing is not ethical; therefore TPMs should only be used as a secure computing feature on LANs or WANs owned by a single entity, for verification between devices on their private network and other devices also on the same private network, and should not be an Internet-wide technology.

Unfortunately, the current trend in computing is towards more consolidated power in the hands of major corporations, and it should surprise no one that TPMs are likely to be required in the hardware specifications of future versions of Windows. I encourage everyone to fight this by supporting the Electronic Frontier Foundation, writing your Congressman, or otherwise become politically active in efforts to keep the Internet public rather than owned.

At the very minimum, if such power is to exist as an internet-wide phenomenon, it should be in the hands of the elected representatives of the people — the government — and not in the hands of corporations and think-tanks.

In any case, for the moment GGG cannot assume that clients have a TPM (it is hardware, after all), so they have to design assuming that trusting the client is impossible. In the future, maybe GGG could trust the client... but they'd be morally wrong if they did so, for further contributing to a TPM-based Internet. Unless the government stepped in to regulate, in which case PoE's global reach might still make TPM-based trust difficult to implement (due to having to deal with a variety of governments).

In other words, gonzaw, yes, it's theoretically possible, but it's still not really an option.


Right, so in an attempt that "hacker users" don't get that data, TPM also makes it so that "legit users" can't see that data as well, right?

But does this stem from the fact the computer has TPM, or does it stem from software that makes use of this TPM to encrypt their data (in user's machines?)
If it's the 2nd one, then, if it is shown that the software/corporation/etc uses TPM in an "ethical" manner, then is there still a problem?

For example, imagine the PoE client code is open source. Anybody can see what it does. Now imagine the PoE client calls TPM as the private key I mentioned in my posts (to decipher packets received from the server, to use as a common key with the server for authentication).
If we look at the source, and notice this "TPM lookup" is called EXACTLY once, and in this exact place, wouldn't we know that there is nothing unethical going on with TPM?
Okay, this exact example would still have the "virtualization" problems and the like. So imagine the PoE client uses TPM for ANYTHING necessary to prevent hackers from getting the data in-memory, etc. Basically, it uses TPM not only to protect the packets/etc but also to protect it's own memory.
If we know where this is done and how, would it still be as unethical as you say?
Users don't really need to know the PoE data it has currently right? I mean...the user does know, via the PoE GUI (he can see he received a Flask from loot in the screen, thus he knows the packet from the server returned a flask, or the client generated a flask in-memory).
Or am I missing something?


Although....yeah it wouldn't be good business for GGG to force everybody to get that TPM chip before playing PoE :P
"
grasmann wrote:

resyncing the player and the mobs on screen every 500ms by default. Basically what "/oos" does.

Perhaps have the udp stream only activate when enemies are around. (that would help lessen the load) But then again, while grinding at a high level, when arent you surrounded by enemies?...
Perhaps a control code to set into motion this functionality when received via the servers established tcp connection. This way when the the servers cant handle this additional load it can be simply turned off.
For years i searched for deep truths. A thousand revelations. At the very edge...the ability to think itself dissolves away.Thinking in human language is the problem. Any separation from 'the whole truth' is incomplete.My incomplete concepts may add to your 'whole truth', accept it or think about it
Last edited by SkyCore#2413 on Nov 23, 2013, 5:49:31 PM
Sorry guys, but 'brute-forcing' synchronization is just not the answer. If this was feasible, GGG obviously would have already done it. The amount of rubber-banding that would result from this would make the game unplayable.
Last edited by qwave#5074 on Nov 23, 2013, 5:55:19 PM
"
qwave wrote:
Sorry guys, but 'brute-forcing' synchronization is just not the answer. If this was feasible, GGG obviously would have already done it. The amount of rubber-banding that would result from this would make the game unplayable.
qwave may be correct (for once). UDP would make continuous transmission of resynchronization data — a kind of constant /oos — cheaper than the same service (constant resynch) using TCP. However, the more selective/non-constant resynchronization becomes, the less attractive UDP becomes.

I sincerely believe deterministic prediction for monster animation is the best change we can hope for, with maybe UDP resync in the future if GGG's servers can handle the bandwidth for more frequent resynchronization.
When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted.
"
qwave wrote:
Sorry guys, but 'brute-forcing' synchronization is just not the answer. If this was feasible, GGG obviously would have already done it. The amount of rubber-banding that would result from this would make the game unplayable.


And if your idea was feasible, than GGG would have already done it

Oh wait...
"
gonzaw wrote:

Right, so in an attempt that "hacker users" don't get that data, TPM also makes it so that "legit users" can't see that data as well, right?


If you view {de,en}cryption as signWithKey :: Key -> [Word8] -> [Word8] then TPM curries it to sign :: [Word8] -> [Word8] by binding the first parameter. Look at TPM_Sign in the spec.

"
But does this stem from the fact the computer has TPM, or does it stem from software that makes use of this TPM to encrypt their data (in user's machines?)
If it's the 2nd one, then, if it is shown that the software/corporation/etc uses TPM in an "ethical" manner, then is there still a problem?


The TPM itself is a device and has no ethical implications. How it's used does matter. People are generally concerned with using the TPM to prevent them from viewing data that they have legitimate access to, etc.

"
For example, imagine the PoE client code is open source. Anybody can see what it does. Now imagine the PoE client calls TPM as the private key I mentioned in my posts (to decipher packets received from the server, to use as a common key with the server for authentication).
If we look at the source, and notice this "TPM lookup" is called EXACTLY once, and in this exact place, wouldn't we know that there is nothing unethical going on with TPM?


Sure. It doesn't make sense though. Consider using debug registers to break immediately after any remote attestation is done and inject code in the kernel's interrupt handler.

Generally it does not matter if you trust ring N if you can't trust rings [0..N-1] so you will need to control the entire boot chain including device drivers. Good luck with that if you're releasing consumer software.

"
Okay, this exact example would still have the "virtualization" problems and the like. So imagine the PoE client uses TPM for ANYTHING necessary to prevent hackers from getting the data in-memory, etc.


This is an O/S function, not a TPM function. The TPM only prevents you from getting specific data (cryptographic keys) as far as I'm aware.

"
Although....yeah it wouldn't be good business for GGG to force everybody to get that TPM chip before playing PoE :P


In 2015 in order to pass Windows hardware certification you will need a TPM installed.
Last edited by genericacc#3481 on Nov 23, 2013, 6:11:51 PM
"
deteego wrote:
And if your idea was feasible, than GGG would have already done it


Rhys said: "The concept is not impossible, I think, but it isn't really feasible. It's simply too big of a change."

They could have done it in the early days of PoE, but it's too late now.
Last edited by qwave#5074 on Nov 23, 2013, 6:28:07 PM

Report Forum Post

Report Account:

Report Type

Additional Info