Technical solution to eliminate desync in single-player sessions

"

SkyCore wrote:

"

RogueMage wrote:

Yes, this is what Scrotie proposed months ago

Dont suppose you have a link?

Oldest I could easily google was this, I think I proposed it earlier than that.

However, I am no longer necessarily of the idea that the most frequent resyncs are necessarily the best resyncs. Also, resyncs are resyncs; they don't prevent desync, they simply fix desync when it does occur. I'm far more keen on deterministic prediction of monster AI at this point.

"

genericacc wrote:

"

RogueMage wrote:

the completely optional nature of the update stream would make UDP packet loss a non-issue.

I don't understand why people care so much about this. TCP loses packets also, they're just resent, and you don't necessarily need the strict ordering TCP imposes. I'll agree with the rest of it, though.

A resent packet is a delayed packet.

A delayed packet is a desynced packet.

A delayed packet may contain data that is no longer relevant (i.e. if your resent packet is delayed 4s, and it contains mob position, what do we care about the position of mobs 4 seconds ago)

"

Skogenik wrote:

If you take a look at the amount of network traffic that is actually generated between the client and the server, I have a strong concern that using UDP will lead to Congestion collapse, rather quickly.

That's why it's designed to be completely optional and triageable. Both server and client can use a wide variety of metrics to determine when the UDP stream would require too much overhead to maintain, and suspend either its broadcast or reception for any length of time.

"

Skogenik wrote:

Unfortunately, many people are behind a NAT, whether they know it or not and Getting UDP through NAT requires a specialized technique that is by no means standardized.

Again, since the UDP stream is completely optional, players who cannot or choose not to enable it will suffer absolutely no drawbacks. PoE would continue to work exactly as it does now!

"

Skogenik wrote:

If I were GGG's network programmer, I think the risk of making it so that a large percentage of users can't use the game at all...

Absolutely wrong, the game would never be less usable than it is today.

"

RogueMage wrote:

"

Skogenik wrote:

If you take a look at the amount of network traffic that is actually generated between the client and the server, I have a strong concern that using UDP will lead to Congestion collapse, rather quickly.

That's why it's designed to be completely optional and triageable. Both server and client can use a wide variety of metrics to determine when the UDP stream requires too much overhead to maintain, and suspend either its broadcast or reception for any length of time.

At that size, I don't think the overhead of TCP/IP routing and ack's is actually a bad thing.

"

Skogenik wrote:

Unfortunately, many people are behind a NAT, whether they know it or not and Getting UDP through NAT requires a specialized technique that is by no means standardized.

Again, since the UDP stream is completely optional, players who cannot or choose not to enable it will suffer absolutely no drawbacks. PoE would continue to work exactly as it does now!

"

Skogenik wrote:

If I were GGG's network programmer, I think the risk of making it so that a large percentage of users can't use the game at all...

Absolutely wrong, the game would never be less usable than it is today.

So essentially this proposal is akin to transmitting /oos data over UDP?

"

RogueMage wrote:

Absolutely wrong, the game would never be less usable than it is today.

In my defence; I've never had the sort of issues that some people seem to have.

I did experience a number of disconnects after patch day, but rebooting my Modem pretty much cleared all of that up.

The point I'm making about UDP isn't about it's suitability as a backup channel or anything like that; I'm simply trying to shine light on the fact that there are some rather important reasons as to why it's simply not the Panacea that people think it is.

That said, I'm not trying to poopoo the idea either; I will be very happy for someone to disprove the technical nature of my concerns - after all, this thread is somewhat of a thinktank now, and I think it's valuable and really cool that members of this community are trying to help GGG to get this sorted out.

To extend what I was saying earlier about the amount of packets that are sent and the size that they are, the majority of the traffic consists of a 1 or 2 byte message with a 64byte header.
What did surprise me though was the frequency of said packets, Wireshark was literally scrolling faster then I could read it, even though I'd filtered it specifically to only monitor my local host talking to the server, and vice versa.

I have sent a report to GGG about some oddities I saw too, I hope it helps but I don't want to go into that just yet, in-case there's a very good reason for the things I saw ;)

"

Sachiru wrote:

So essentially this proposal is akin to transmitting /oos data over UDP?

Yep.
Best part about this proposal is that i can imagine it being a very easy job. A week or two perhaps. But only GGG could really say for sure. Perhaps a day for someone who can code a hell of a lot faster than i, and has prior experience in the code.

"

Sachiru wrote:

So essentially this proposal is akin to transmitting /oos data over UDP?

No, not at all! When you send an /oos you are asking the server to manually resync your client. That's drastic and time consuming and can create abrupt (though expected) rubberbanding.

The UDP update stream is not used to resync the client, it's intended to reduce the need for resyncs and minimize the abrupt visual disturbance of rubberbanding.

One way to regard the UDP update stream is as a series of positional hints that give the client timely clues as to where the server's simulation is proceeding. Since it's a UDP stream, these positional hints can be made available with far less network latency than an /oos resync process. And since the client uses the hints to make movement vector corrections rather than abrupt player or enemy position changes, it avoids the visual disturbances produced by rubberbanding.

"

RogueMage wrote:

"

Sachiru wrote:

So essentially this proposal is akin to transmitting /oos data over UDP?

No, not at all! When you send an /oos you are asking the server to manually resync your client. That's drastic and time consuming and can create abrupt (thought expected) rubberbanding.

The UDP update stream is not used to resync the client, it's intended to reduce the need for resyncs and minimize the abrupt visual disturbance of rubberbanding.

One way to regard the UDP update stream is as a series of positional hints that give the client timely clues as to where the server's simulation is proceeding. Since it's a UDP stream, these positional hints can be made available with far less network latency than a /oos resync process. And since the client uses the hints to make movement vector corrections rather than abrupt player or enemy position changes, it avoids the visual disturbances produced by rubberbanding.

Well it would be a hell of a lot easier to just reuse the /oos function. But your way would be more efficient, yes. (assuming you can get it to work)
Rendering things to the screen where the client KNOWS the position wrong seems worse than jerky resynchs in my mind. Id rather have accuracy than visual ascetics.
Perhaps do some rendering magic. Ever see the necro-mongers in the chronicals of riddick? That would be a cool affect. You see both positions simultaneously with some sort of wisp between the two. So on our rendered screen we dont have the jerkiness, yet we still know the most accurate and up to date information of the true state of the game.

"

RogueMage wrote:

"

Sachiru wrote:

So essentially this proposal is akin to transmitting /oos data over UDP?

No, not at all! When you send an /oos you are asking the server to manually resync your client. That's drastic and time consuming and can create abrupt (thought expected) rubberbanding.

The UDP update stream is not used to resync the client, it's intended to reduce the need for resyncs and minimize the abrupt visual disturbance of rubberbanding.

Sorry, but that's just wrong.

By the time the client's commands reach the server, you are out of time; that is the deadline. You don't have time to send anything back to the client in terms of desync prevention; anything you send back will be resyncing the client, because if the client has it wrong at that point, it's already going to be out of sync.

UDP is the ideal protocol for continuous, automatic resyncing. Calling the UDP suggestion /oos streaming is actually a very accurate description. It cannot be desync prevention (even if it can limit desync duration), and it is not the best protocol for selective resyncs.

The reasoning to reject UDP is essentially this: if we can get halfway decent prediction by the client, thus not desync that often in the first place, then continual correction is no longer required, therefore we don't need UDP.

I agree with Scrotie on this one.

UDP as a method of transmitting partial /oos data every, say, 500ms (for those connections with high latency) would be nice. (the 500 ms count is for people with ~500 ms ping, no point sending position data every 5 ms if they receive it 500ms later, this is basically tuned towards average player ping)

The thing about resync is that it's hard only for the server, not for the client. This is evidenced by the fact that when we OOS, the resync is practically instant - there's no loading time or processing or whatever unless your computer is terribly ancient.

The only consideration why GGG refuses to allow /oos on a timer is that if everyone did it the performance impact on the server is massive, due to it sending /oos data all the time.

Thus, a possible compromise is this:

GGG sends /oos data relevant to monster position in a specified radius (say, Y units) every X milliseconds.

We don't really particularly care about monster positions two and a half screens away, nor do we want to overload the server by having it transmit that irrelevant data that often. Also, ranged can easily get around without desync that much, it's only melee-centric skills (I'm looking at you, Cyclone) that cause severe desync issues, due to mob presence within melee range.

If monster position and attack data for monsters within a small range of the character were transmitted regularly through UDP, I believe that this should alleviate the desync issues.

Of course, some sort of algorithm should be developed that should help the server know which mobs are in Y range of the client, so that it sends positional data correctly and in time.