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

"
ScrotieMcB wrote:
@Dao: Server-to-client needs the timestamp, to properly toss out UDP packets if they're older than those already received. Client-to-server does not need the timestamp, because it doesn't care what time the client says it is.


my example of how to exploit his vulnerable design doesn't need to know _anything_. it needs to just fake a delay no matter what.
the path that can be chosen is not the correct path to choose. such is the nature of the Dao.
"
ScrotieMcB wrote:
@Dao: Server-to-client needs the timestamp, to properly toss out UDP packets if they're older than those already received. Client-to-server does not need the timestamp, because it doesn't care what time the client says it is.

Just nitpicking though; most of what you're telling gonzaw is dead-on.

@gonzaw: to be brutally honest, I lost interest in your client-trusting time-rewinding scheme pages ago and I'm just waiting for you to drop it.


Actually, if you just use a "next_seq" number you don't need the server to send a timestamp to the client.

Again, borrow that stuff from TCP, you start with "next_seq = X" (in the client), and if you get any UDP from the server with NS<X you ignore it, if you get one with NS==X you take it and put NS=X+1
If you get a UDP with NS=Y so Y>X, you take it and put your NS=Y+1

The server would just have an auto-increase number he sends with each UDP packet to the client, and with each packet sent he increases it, and he doesn't care about anything else.

Thus no relation between the TS the client would send to the server and what the server sends to the client (or just have no timestamp ever in server->client communications)
Last edited by gonzaw#3022 on Jun 20, 2013, 12:08:28 AM
Ok fine I'll stop, whatever
"
gonzaw wrote:
"
ScrotieMcB wrote:
@Dao: Server-to-client needs the timestamp, to properly toss out UDP packets if they're older than those already received. Client-to-server does not need the timestamp, because it doesn't care what time the client says it is.
Actually, if you just use a "next_seq" number you don't need the server to send a timestamp to the client.
That actually is a valid alternative to timestamps. Doesn't really get around all the other problems Dao listed, but look on the bright side: you're not wrong this time.
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.
So this is that? No more discussion?

I'd prefer some discussion about being "wrong" (which hey! Maybe we can figure out something to make me "right") other than no discussion at all
"
gonzaw wrote:
I'd prefer some discussion about being "wrong" (which hey! Maybe we can figure out something to make me "right") other than no discussion at all
Back to the original topic...

As I mentioned some time ago, it's clear that TCP is best for very static things, and UDP best for very fluid things, but the maps (both the main view to include non-destroyable objects such as trees, streams, walls, and the minimap version of the same objects) don't really fit nicely into classification; the map isn't exactly static, but it also represents a rather large chunk of data which might cause some bandwidth issues somewhere if it's rebroadcast with every single resynch. One thing to note for this is that, especially on the GGG side, UDP resynchs would be sent out multiple times per second, which means even small bandwidth increases multiply large in a hurry (hence the need to be concise).

Let's assume that we don't want map data in the ultra-frequent UDP stream as a result. Our options then become:
  • Toss maps in with the TCP data.
  • Make a separate, less-frequent UDP stream for map data.

Which one? Thoughts?
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.
I don't care how it happens.. every single fucking mob higher then 2+ i get desync like crazy using dual strike melee splash.. keep dieing becuase of this bullshit

IGN : MxZeal _____________________________________________ Youtube.com/user/mshadow1994
"
ScrotieMcB wrote:
"
gonzaw wrote:
I'd prefer some discussion about being "wrong" (which hey! Maybe we can figure out something to make me "right") other than no discussion at all
Back to the original topic...

As I mentioned some time ago, it's clear that TCP is best for very static things, and UDP best for very fluid things, but the maps (both the main view to include non-destroyable objects such as trees, streams, walls, and the minimap version of the same objects) don't really fit nicely into classification; the map isn't exactly static, but it also represents a rather large chunk of data which might cause some bandwidth issues somewhere if it's rebroadcast with every single resynch. One thing to note for this is that, especially on the GGG side, UDP resynchs would be sent out multiple times per second, which means even small bandwidth increases multiply large in a hurry (hence the need to be concise).

Let's assume that we don't want map data in the ultra-frequent UDP stream as a result. Our options then become:
  • Toss maps in with the TCP data.
  • Make a separate, less-frequent UDP stream for map data.

Which one? Thoughts?


Isn't the map sent through TCP and fully loaded in the client when you change instances?

Why would you want to send map data more than once?
"
gonzaw wrote:
Isn't the map sent through TCP and fully loaded in the client when you change instances?

Why would you want to send map data more than once?
Protection against maphack; sure, we're already protecting against teleports and the like, but I don't want hackers to automatically know where the next exit is, either. So the plan was to spoonfeed it.
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.
...wat?

But how would the game work then?

You just see a little portion of the map and every time you move the portions you visited are erased? So you can't complete the minimap in the client?

Why is the exit thing necessary? So they don't run bots that run straight to the exit all the time and finish everything fast?
...is that a problem at all?

Report Forum Post

Report Account:

Report Type

Additional Info