Reasons Why Desync Happens (Thoroughly Explained /w Cited Commentary On Fixes & Focuses Info)

Some of you realllly lack in networking knowledge / using odd terms. I'm not even going to try to correct this any more. go read a book or something.

"

Dao wrote:

EDIT:
re-read your posts. you haven't outlined any solution beyond very abstract and common sense things. which do not suggest how to solve desnyc, and do not suggest anything that perhaps isn't already implemented in game.

Well that's kind of vague. Any specific things about what I said that make you say that?
I don't think what I said was very abstract, but rather practical instead.
Also I don't work for GGG (and haven't noticed this stuff in the manifesto) so I can't know if it's already in the game or not :P
I'd guess that it's not.

"

you spoke of the encryption and the protocol, which is the part i commented on.

you always assume that there are some unrelated hackers that are trying to disturb an innocent player, not that the player is the one who wants to hack to save the character from death (and other things). if you assume that one of the players wants to hack, then for example (commenting on one thing you said), the packets don't have to be in order because that client can, rather quickly, fake a packet with an earlier timestamp, and thus save himself from death, if the server is too trusting.

moreover, if one of the players wants to hack, then the encryption is irrelevant, because that player has the key. not a single one of the encryption methods you mentioned is of any value.

Okay. I was under the assumption the client would be hard to "crack", and the encryption would be in code (instead of being in a visible .key file or something)

Considering the benefits of hacking it (imo) would not be that good the encryption thing alone would even deter people from trying as well (and not spend hours and hours and stuff hacking the client and the network, etc, just for the timestamp thing).

"

please clarify where in your solution you want to trust the client more than it is currently trusted (you can use the manifesto post on desync to find out, in general, where it is not currently trusted). and then i can determine if, from my point of view, it would be vulnerable, and then you can suggest a solution to that vulnerability.

The ONLY thing it "trusts" the client is in the timestamp thing (at least in the "primitive" solution I mentioned).

By doing other stuff then I think it wouldn't even need to "trust" it that much.


I'd like to know if that thing i said earlier ("with the timestamps and protocol I mentioned, there's no way a 'hacker' can set a fake timestamp with time X, if a command from the client was already sent with time X+1")

I was kind of assuming, the dude would be playing in the client (where else would he "play"?), and would have a custom program that would create and send the fake packets and shit near. Then he can play and disrupt the stuff by sending fake packets quickly (or maybe automate it with a hidden process or something).

I don't know what other case of "hacking" or "cheating" you can do with the timestamp thing that would actually matter.
If you say stuff like man-in-the-middle with OTHER players....then they can easily just send a fake packet to the server telling it that the guy is walking into a mob of high-level monsters and never attacking, and tell the client that the mobs have low attack (or something) and he can already screw with the guy WITHOUT taking into account the timestamp thing, thus I wouldn't even bother discussing that (regarding the timestamp thing, i.e it doesn't make matters worse, at least not to my knowledge).


Anyways I said my idea wouldn't be the "best one ever", but it can be the start of an incremental process to redefine it and improve it until you get something that really takes down desync (kind of how in networking classes you start defining a simple transport protocol, then adding packet control to it, then flow control to it, etc until you 'redefine' it into TCP :D )

"

TheHeffNerr_ wrote:

Some of you realllly lack in networking knowledge / using odd terms. I'm not even going to try to correct this any more. go read a book or something.

an interesting related story, i have an uncle who wrote a custom database program for a bookstore network, one which was secure and comfortable to work with. he can't speak a word of english, and when i asked him questions, i couldn't understand the terms he spoke of, so he explained things to me in words i could understand.

anyway, i read books in one language (most notable, though not related to networking, would be Donald E. Knuth's algorithm books), when i could find somebody to talk to (short of my uncle who used the first language), it was in another language, and of course, whatever i learned from the internet was in english. not to mention many times i would skip the "human language" and just dive into code, using anything written as a reference to the code and skimming through it.

also, if you are interested in chinese philosophy, and then understand the term that is my nick name, you would surely know that my thought nowadays is that words are wind and the meaning is what counts (i used to be quite pedantic though), and i sometimes pick up terms that are used in the discussion - sort of redefine my own vocabulary on the spot to fit the terms used in the conversation - and use those terms even if others are more fitting.

with all that said (and you adding a part about networking knowledge not just odd terms), i would not object to corrections, which would help straighten the line - provide some order to the discussion, and i would not object to be educated if i am wrong or off somewhere, so feel free to contribute.

though i have no practical experience / notable accomplishments to back this up myself, i think practical experience beats theoretical knowledge every time, and my uncle is an example of it (he did a hell of a lot more than that one big project he sold).

"

gonzaw wrote:

Spoiler

"

Dao wrote:

EDIT:
re-read your posts. you haven't outlined any solution beyond very abstract and common sense things. which do not suggest how to solve desnyc, and do not suggest anything that perhaps isn't already implemented in game.

Well that's kind of vague. Any specific things about what I said that make you say that?
I don't think what I said was very abstract, but rather practical instead.
Also I don't work for GGG (and haven't noticed this stuff in the manifesto) so I can't know if it's already in the game or not :P
I'd guess that it's not.

many things have been said since then. could you please write your suggestion, and only it and no other discussion about protocols or encryption, in a detailed manner? then i could comment further

"

Spoiler

"

you spoke of the encryption and the protocol, which is the part i commented on.

you always assume that there are some unrelated hackers that are trying to disturb an innocent player, not that the player is the one who wants to hack to save the character from death (and other things). if you assume that one of the players wants to hack, then for example (commenting on one thing you said), the packets don't have to be in order because that client can, rather quickly, fake a packet with an earlier timestamp, and thus save himself from death, if the server is too trusting.

moreover, if one of the players wants to hack, then the encryption is irrelevant, because that player has the key. not a single one of the encryption methods you mentioned is of any value.

Okay. I was under the assumption the client would be hard to "crack", and the encryption would be in code (instead of being in a visible .key file or something)

the encryption algorithm is in the code, the key is in memory. it all does not matter, because you have the client which encrypts, and you can use existing code (without even knowing what it is short of being an encryption algorithm). you don't even need to reverse-engineer that part of the client, just identify what it is and keep it as is. you control what goes in to be encrypted and sent to the server.

"

Considering the benefits of hacking it (imo) would not be that good the encryption thing alone would even deter people from trying as well (and not spend hours and hours and stuff hacking the client and the network, etc, just for the timestamp thing).

there is no encryption thing to worry about! what is encrypted would be sent encrypted to the server, what is received from the server would be decrypted. you, as the client, have access to all of it. if you would want to try something funny, you would not need to worry about any of it.

"

Spoiler

"

please clarify where in your solution you want to trust the client more than it is current1ly trusted (you can use the manifesto post on desync to find out, in general, where it is not currently trusted). and then i can determine if, from my point of view, it would be vulnerable, and then you can suggest a solution to that vulnerability.

The ONLY thing it "trusts" the client is in the timestamp thing (at least in the "primitive" solution I mentioned).

By doing other stuff then I think it wouldn't even need to "trust" it that much.

again, please repeat your solution again as a summary of what you propose. then everybody can look at it and comment.

"

I'd like to know if that thing i said earlier ("with the timestamps and protocol I mentioned, there's no way a 'hacker' can set a fake timestamp with time X, if a command from the client was already sent with time X+1")

the hacker is the player, the player is the hacker. being in that position, the player/hacker can send whatever he wants from his computer to the server. there are no limiting rules. what a potential hacker would want to do is to send something which is both meaningful, so the server won't discard it, and at the same time malicious, serving the hacker's purpose. and this is true to all levels of the communication, including but not limited to - modifying the TCP and IP headers.

"

I was kind of assuming, the dude would be playing in the client (where else would he "play"?), and would have a custom program that would create and send the fake packets and shit near. Then he can play and disrupt the stuff by sending fake packets quickly (or maybe automate it with a hidden process or something).

I don't know what other case of "hacking" or "cheating" you can do with the timestamp thing that would actually matter.
If you say stuff like man-in-the-middle with OTHER players....then they can easily just send a fake packet to the server telling it that the guy is walking into a mob of high-level monsters and never attacking, and tell the client that the mobs have low attack (or something) and he can already screw with the guy WITHOUT taking into account the timestamp thing, thus I wouldn't even bother discussing that (regarding the timestamp thing, i.e it doesn't make matters worse, at least not to my knowledge).

the timestamp was just an example. forget the timestamp. just write what you suggest and we will continue there.

"

Dao wrote:

"

Spoiler

"

you spoke of the encryption and the protocol, which is the part i commented on.

you always assume that there are some unrelated hackers that are trying to disturb an innocent player, not that the player is the one who wants to hack to save the character from death (and other things). if you assume that one of the players wants to hack, then for example (commenting on one thing you said), the packets don't have to be in order because that client can, rather quickly, fake a packet with an earlier timestamp, and thus save himself from death, if the server is too trusting.

moreover, if one of the players wants to hack, then the encryption is irrelevant, because that player has the key. not a single one of the encryption methods you mentioned is of any value.

Okay. I was under the assumption the client would be hard to "crack", and the encryption would be in code (instead of being in a visible .key file or something)

the encryption algorithm is in the code, the key is in memory. it all does not matter, because you have the client which encrypts, and you can use existing code (without even knowing what it is short of being an encryption algorithm). you don't even need to reverse-engineer that part of the client, just identify what it is and keep it as is. you control what goes in to be encrypted and sent to the server.

Yeah I was thinking both algorithm AND key could be in code (you know, just like a static read only public field or something like that)

"

"

Considering the benefits of hacking it (imo) would not be that good the encryption thing alone would even deter people from trying as well (and not spend hours and hours and stuff hacking the client and the network, etc, just for the timestamp thing).

there is no encryption thing to worry about! what is encrypted would be sent encrypted to the server, what is received from the server would be decrypted. you, as the client, have access to all of it. if you would want to try something funny, you would not need to worry about any of it.

If you don't hack the client...then yes if you are a hacker you HAVE to worry about the encryption (mainly figuring out how to decypher it).

Assuming hackers just start as a clean state and would decide to hack the client from scratch to gain some advantage, I think the risk is not worth the reward for them (risk: Hours of figuring out the code, working on it, etc maybe even spend money; reward: very little basically if it's about the timestamps alone).

If a hacker didn't feel the need to hack the POE client before, I think he won't feel the need to hack it again if we introduce the "timestamp" thing.



Anyways, okay summarized thing here:


1)Every POE packet has a timestamp of when it was emitted (by the client)
2)Server keeps a local timestamp (of course)
3)Server keeps a "threshold" variable, which changes according to the RTT between the client and the server (server's local TS - packet's TS)
4)Just like TCP (basically), change this threshold variable according to the average of those RTT, and variance and shit
5)The server keeps the "game state", for every "game tick" (basically each different "time" in the game) since "threshold" time before (so the window of these game states is [threshold-Now]).
6)When a packet arrives with a TS before the current one (most likely every time), the server firsts rolls back to the game state that was at that time, THEN executes the command from that packet (or whatever it has to process)
7)After this happens he sets the "threshold" variable again from (4)
For the "security" reasons, this is what I thought about:

-The server saves the TS of the last received packet. If he receives any new packet with a TS smaller than that one, he ignores it
-The server communicates with the client only through TCP in this regard (not streaming)
-The server has a "client id" or similar that identifies the client that is sending him the packet
-This "client id" would most likely be shared in a "handshake" of sorts, more on this below

Here's how I don't know how it works in POE, but I'll post both scenarios anyways:
1)Client opens a new TCP connection when he sends a new packet, after sent closes it:
-If the server has 2 TCP connections opened, where he receives 2 packets with the same "client id", he uses the one with the earliest TCP connection (the one that opened first), and ignores the other one
-In this case the "client id" is sent with the data packet.

2)Client and server always have a "command" TCP connection open while the game is up:
-If the server gets a new TCP connection with the same "client id" as a previous TCP connection he already has open, he closes that new connection and ignores it
-In this case the "client id" is sent in a "handshake" packet as soon as the TCP connection is opened (when game starts, when combat starts, whenever it matters for the communications to start)


If those are true, then I believe this happens:
A "hacker" can only send a fake packet with a fake timestamp to the server, and have the server recognize it, then:
[If (2) holds true] He must send it in the same TCP connection as the real client does, but if his "fake" TS has time X, he can't send it after the client already sent a packet with TS X+1
[If (1) holds true] He must either send it in the same TCP connection as a packet that's already being sent (in which case it arrives after it), or he must send it AFTER said packet opened the connection, sent the packet and closed it again. Therefore same thing applies
Which would mean the hacker can't send a packet with TS X if the client already sent a packet with TS X+1, thus the "hacker" can't 'undo' anything that was done, and can only 'hack' into the future....which is basically the same as hacking it as it is now, thus TS would make no difference.


I'm actually not that sure, since I'm not sure how the hacker would interact with the TCP protocol client-side if he decides to "hack" the same TCP connection (basically send data packets with the same ip+port as the real tcp connection).
Yeah that seems like a lot of possibilities (with the different sequence numbers, out-of-order data that's being "inserted" into the stream, stuff like that) that I have no idea about :P

"

gonzaw wrote:

Yeah I was thinking both algorithm AND key could be in code (you know, just like a static read only public field or something like that)

a key can't be static. it is most likely generated every time you connect to the server (though i don't know which algorithm they use, if any)

"

If you don't hack the client...then yes if you are a hacker you HAVE to worry about the encryption (mainly figuring out how to decypher it).

i will repeat again, assume the player is the hacker, and assume the client is compromised.

"

Assuming hackers just start as a clean state and would decide to hack the client from scratch to gain some advantage, I think the risk is not worth the reward for them (risk: Hours of figuring out the code, working on it, etc maybe even spend money; reward: very little basically if it's about the timestamps alone).

If a hacker didn't feel the need to hack the POE client before, I think he won't feel the need to hack it again if we introduce the "timestamp" thing.

you don't just not close the door on the other side of the building because - hey, nobody would circle around the entire building just to steal something. no, you lock all the doors. most important rule of security (real life one as well as internet one) is to lock everything that you can.

rule of thumb on the internet - there will always be somebody with enough spare time to waste, sufficient knowledge, and some motivation to go into all the places you thought nobody would go.

"

Anyways, okay summarized thing here:


1)Every POE packet has a timestamp of when it was emitted (by the client)
2)Server keeps a local timestamp (of course)
3)Server keeps a "threshold" variable, which changes according to the RTT between the client and the server (server's local TS - packet's TS)
4)Just like TCP (basically), change this threshold variable according to the average of those RTT, and variance and shit
5)The server keeps the "game state", for every "game tick" (basically each different "time" in the game) since "threshold" time before (so the window of these game states is [threshold-Now]).

just trying to follow your description. the way i understand your words, and what threshold is, it should be:

[threshold - (now - saved_time)]

<EDIT> or: [threshold - game_ticks] </EDIT>

and not:

[threshold - now]

"

6)When a packet arrives with a TS before the current one (most likely every time), the server firsts rolls back to the game state that was at that time, THEN executes the command from that packet (or whatever it has to process)

so the server is the one syncing with the client ?! besides the manifesto already stating that it will not happen, and besides the fact that it will be highly problematic with more than one player, i already see a vulnerability.

* the client, who's timestamp you trust and use, can artificially inflate the value of your threshold by deliberately sending falsified reduced timestamps, and responding to the server's queries according to that faked delay.

* then, while the server thinks that your threshold is huge and you receive things slowly while you actually get them quite quickly, you can send an alt+f4 with a timestamp prior to the death.

* because of the inflated threshold, all your prior packets will be with a (falsified) lower timestamp than they should, and you could easily catch the death within the margin and fake an alt+f4 to be prior.

the margin is: the value between the server's latest timestamp with the death as the upper boundary, and your most recent falsified timestamp as the lower boundary.

conclusion: the server does not, under any circumstances, sync with the client. the client syncs with the server.

"

7)After this happens he sets the "threshold" variable again from (4)
For the "security" reasons, this is what I thought about:

-The server saves the TS of the last received packet. If he receives any new packet with a TS smaller than that one, he ignores it

the margin covers this. server won't ignore.

<EDIT> also does not account for the natural chaos of the internet and packets coming out of order, which happens as i understand it </EDIT>

"

-The server communicates with the client only through TCP in this regard (not streaming)
-The server has a "client id" or similar that identifies the client that is sending him the packet
-This "client id" would most likely be shared in a "handshake" of sorts, more on this below

Here's how I don't know how it works in POE, but I'll post both scenarios anyways:
1)Client opens a new TCP connection when he sends a new packet, after sent closes it:
-If the server has 2 TCP connections opened, where he receives 2 packets with the same "client id", he uses the one with the earliest TCP connection (the one that opened first), and ignores the other one
-In this case the "client id" is sent with the data packet.

2)Client and server always have a "command" TCP connection open while the game is up:
-If the server gets a new TCP connection with the same "client id" as a previous TCP connection he already has open, he closes that new connection and ignores it
-In this case the "client id" is sent in a "handshake" packet as soon as the TCP connection is opened (when game starts, when combat starts, whenever it matters for the communications to start)

number 2 is the most likely scenario, and i don't see any reasoning behind constantly opening and closing connections, unless it is HTTP which it is not - it is a real time ARPG.

the socket that the operating system opens for the server is the "client id".

why do you need to send it to the client is what i don't understand. there is an open TCP connection, and if it closes it means disconnect. so while it is open you have the socket to identify the client and you don't need any more. you write a hook (i think it is called that) to the event of receiving data from an opened socket, the operating system provides you with the socket, and you by that socket know who it is. whenever something happens in the game on the server, the server knows which sockets are in the area and sends them the information.

you are complicating things and sending the client unnecessary data that should only be kept server side.

"

If those are true, then I believe this happens:
A "hacker" can only send a fake packet with a fake timestamp to the server, and have the server recognize it, then:
[If (2) holds true] He must send it in the same TCP connection as the real client does, but if his "fake" TS has time X, he can't send it after the client already sent a packet with TS X+1
[If (1) holds true] He must either send it in the same TCP connection as a packet that's already being sent (in which case it arrives after it), or he must send it AFTER said packet opened the connection, sent the packet and closed it again. Therefore same thing applies
Which would mean the hacker can't send a packet with TS X if the client already sent a packet with TS X+1, thus the "hacker" can't 'undo' anything that was done, and can only 'hack' into the future....which is basically the same as hacking it as it is now, thus TS would make no difference.

already explained how it works, by inflating your server-side threshold value, no need to 'undo' anything, all timestamps are sequential neat and tidy for the server. still the hack works because the server trusts the client and syncs with the client in your proposed idea.

"

I'm actually not that sure, since I'm not sure how the hacker would interact with the TCP protocol client-side if he decides to "hack" the same TCP connection (basically send data packets with the same ip+port as the real tcp connection).
Yeah that seems like a lot of possibilities (with the different sequence numbers, out-of-order data that's being "inserted" into the stream, stuff like that) that I have no idea about :P

he will not "hack" the same TCP connection. he will hack the client. reverse engineer the client, and write in some code to constantly falsify the timestamps. then add in another piece of code that upon receiving "death" from server, it stops everything and immediately sends an "alt+f4" which actually be sent with a timestamp that is both before the server's "death" timestamp, and after the last timestamp that the client sent, and that because all the other timestamps were falsified.

"

Dao wrote:

"

gonzaw wrote:

Yeah I was thinking both algorithm AND key could be in code (you know, just like a static read only public field or something like that)

a key can't be static. it is most likely generated every time you connect to the server (though i don't know which algorithm they use, if any)

If it's public key don't you just "know" the encryption key of the server?

Speaking of which, even if the client knows the encryption key, and you can get it (via hacking etc), you still don't know the decryption one, so you can't decypher the packets sent from the client to the server right?

"

so the server is the one syncing with the client ?! besides the manifesto already stating that it will not happen, and besides the fact that it will be highly problematic with more than one player, i already see a vulnerability.

Well, it "syncs" with the client but it's subtle.
It's not like the client is the one that tells the server what the damage was, or where the positions are, etc, the server would still be the one in complete control of that

"

Dao wrote:

* the client, who's timestamp you trust and use, can artificially inflate the value of your threshold by deliberately sending falsified reduced timestamps, and responding to the server's queries according to that faked delay.

Oh nice hadn't thought of that before!

Hmm, well, if there's a maximum threshold possible (500ms maybe?) then it would still work.
But if the client keeps doing that then it'd consume more memory from the server, yes.

Not really sure what to do in that case, may be a subtler DOS attack where you have lots and lots of clients doing that, making the server spend more and more resources with a big threshold (maybe...? Dunno if this threshold+game state thing would need that much memory or not).

Well maybe you could keep those game states in a DB instead, and access it sparingly by modifying stuff maybe (so you don't ALWAYS rollback maybe)

"

* then, while the server thinks that your threshold is huge and you receive things slowly while you actually get them quite quickly, you can send an alt+f4 with a timestamp prior to the death.

* because of the inflated threshold, all your prior packets will be with a (falsified) lower timestamp than they should, and you could easily catch the death within the margin and fake an alt+f4 to be prior.

the margin is: the value between the server's latest timestamp with the death as the upper boundary, and your most recent falsified timestamp as the lower boundary.

conclusion: the server does not, under any circumstances, sync with the client. the client syncs with the server.

You lost me here. Why would the threshold matter here at all?
The threshold only determines the size of the "game states window", so if someone is indeed slow the server has enough data to rollback that far back into the past.
The server wouldn't use it to know that "you receive things slowly", or at least how I'm interpreting you saying that

How would that alt+f4 thing work? The client knows he died, then sends the altf4 thing with false timestamp and the server rollbacks? How could that happen?
Can you give me an example of packets sent and stuff?

"

"

7)After this happens he sets the "threshold" variable again from (4)
For the "security" reasons, this is what I thought about:

-The server saves the TS of the last received packet. If he receives any new packet with a TS smaller than that one, he ignores it

the margin covers this. server won't ignore.

<EDIT> also does not account for the natural chaos of the internet and packets coming out of order, which happens as i understand it </EDIT>

Yeah I'm not sure how that "margin" works here and allows the client to bypass this stuff


<stuff>If you use TCP then that's not a problem, the POE-packets (or rather POE-Bytes which you then take to create the received packet) will arrive in order if they come from the same TCP connection...unless some weird TCP hacking goes on which I know nothing about</stuff>

"

"

-The server communicates with the client only through TCP in this regard (not streaming)
-The server has a "client id" or similar that identifies the client that is sending him the packet
-This "client id" would most likely be shared in a "handshake" of sorts, more on this below

Here's how I don't know how it works in POE, but I'll post both scenarios anyways:
1)Client opens a new TCP connection when he sends a new packet, after sent closes it:
-If the server has 2 TCP connections opened, where he receives 2 packets with the same "client id", he uses the one with the earliest TCP connection (the one that opened first), and ignores the other one
-In this case the "client id" is sent with the data packet.

2)Client and server always have a "command" TCP connection open while the game is up:
-If the server gets a new TCP connection with the same "client id" as a previous TCP connection he already has open, he closes that new connection and ignores it
-In this case the "client id" is sent in a "handshake" packet as soon as the TCP connection is opened (when game starts, when combat starts, whenever it matters for the communications to start)

number 2 is the most likely scenario, and i don't see any reasoning behind constantly opening and closing connections, unless it is HTTP which it is not - it is a real time ARPG.

the socket that the operating system opens for the server is the "client id".

why do you need to send it to the client is what i don't understand. there is an open TCP connection, and if it closes it means disconnect. so while it is open you have the socket to identify the client and you don't need any more. you write a hook (i think it is called that) to the event of receiving data from an opened socket, the operating system provides you with the socket, and you by that socket know who it is. whenever something happens in the game on the server, the server knows which sockets are in the area and sends them the information.

you are complicating things and sending the client unnecessary data that should only be kept server side.

Well yeah I dunno how it works so I just let it be any of them.

If you allow only 1 TCP connection per client in a fixed port then yes. I assumed a more general scenario where maybe you could have maybe different clients in different ports and those clients can open connections in different ports as well or something (or however it works in POE).

I was also thinking more about "this specific IP+port is from user X, so I'll update HIS game when I get packets from him".
Basically it'd be like a "POE cookie" (since we aren't using HTTP).
The client is the one sending that "poe cookie", the server doesn't send the data to the client just as servers don't send session data back to web browsers (the server would link a "poe cookie" with an account for instance, the account playing that specific instance where combat and shit is happening).

"

he will not "hack" the same TCP connection. he will hack the client. reverse engineer the client, and write in some code to constantly falsify the timestamps. then add in another piece of code that upon receiving "death" from server, it stops everything and immediately sends an "alt+f4" which actually be sent with a timestamp that is both before the server's "death" timestamp, and after the last timestamp that the client sent, and that because all the other timestamps were falsified.

Yeah I'd like a more thorough example because I'm still not getting it :(
I don't get how by falsifying all the timestamps he can prevent death and what the threshold has to do with it.

Once a "past" timestamp is received by the server and he rollbacks, he sends the updated info back to the client (so the client can sync back).
By falsifying all timestamps to a previous value, you are just "delaying" stuff, where both server and client get in sync.

If you send timestamps X Y and Z, then if you send timestamps X Y-1 and Z-1, when you send the Y-1 one the server rollbacks a little further, but that's where the "new" game is happening.

And like I said X should be less than Y-1 so it would follow with what I said previously wouldn't it? (if you already did action X who cares if you did the next action at Y or Y-1? You can't change action X, you can only send a future action a little bit earlier....but you don't know the future so how would this make you "cheat"?)

I think there is a lot more than what the Op is talking about, in fact i don't even think any of the thing pointed in the op post is even close to be the most important aspec. For me the real problems of desynch come from the collision system, since in this game 2 mobs can't be one of top of an other one (thank god), and let me tell you that i only know a very few old game (like 15 years old) that had that feature. Second the mobs are all in pack which make this problem even more visible. Naturally pathfinding is probably a major aspect too, because it is apparently unable to figure out the pathing correctly and need to refresh so many time that the desynch appear. When you play melee this problem is major and probably is one of the major aspect that make those builds almost unplayable. As an exemple the defense/hp buffer is well set with the new patch, and is probably working very well in a perfect developer environment (lan play), but with server/client infrastructure as player use it, so many time i have my life going near to zero because my toon swing in the air on mobs that are not there anymore, and with 10 mobs around you your life mean crap. I need to literally anticipate the desynch, and run away before it happen to save my toon, apart from that my build is very solid, but no leech for few sec in the middle of a pack = certain death. For me they need a major work on their pathfinding, not on the net aspect, pathfinding should somehow "see" the desynch appear before hand and run an other path before the mobs bump in each other and not after. as it seam to be now.

"

Halagaz wrote:

For me they need a major work on their pathfinding, not on the net aspect, pathfinding should somehow "see" the desynch appear before hand and run an other path before the mobs bump in each other and not after.

The pathfinding system is utterly dependent upon the net aspect to know the current locations of objects. You cannot simply separate the two systems.