Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

"

I'll just say "you're wrong" and leave it at that. I wont be arguing with you over it.

You make a strong case.

A lot of people have explained multiple times why you are wrong, and you have either ignored them or twisted what they say

"

qwave wrote:

"

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.

No they really couldn't unless they wanted to delay their game even more than it was already delayed

"

SkyCore wrote:

Im with you guys. I can see a secondary channel streaming through udp.

Yes, this is what Scrotie proposed months ago, an auxiliary server-to-client position update stream that would reduce the disturbing side-effects of rubberbanding. Implementing it as a separate UDP stream would dramatically reduce network transmission latency and the completely optional nature of the update stream would make UDP packet loss a non-issue. The major advantages of such a system:

* No gamecode revisions required to current server simulation.

* No client dependency on the completely optional update stream.

* No new security issues, since UDP stream is purely server-to-client data.

* No added processing overhead to current TCP netcode implementation.

* No additional network latency - UDP updates can be triaged at any time.

* Supports any number of clients all receiving the same UDP update stream.

How UDP updates could be seamlessly integrated with the client simulation:

1. Client and Server continue to simulate player and enemy movements as usual. Over time, Client's movement predictions diverge from Server's, creating player and enemy position discrepancies.

2. Server periodically encodes a timestamped summary of player and enemy positions into a separate UDP stream, broadcast to all Clients. Server may temporarily suspend UDP stream at any time. UDP stream may lapse or fail to reach Clients without impeding Client simulation.

3. Client verifies UDP packets' integrity and timeliness, discarding unusable data. Client may optionally use UDP stream data to update its internal target positions of enemies and/or players.

4. When Client detects discrepancies between its own and Server's player or enemy positions, it may calculate corrected movement vectors to steer player or enemy units toward updated Server positions.

5. Since UDP position updates result in movement vector corrections rather than abrupt player or enemy position changes (aka rubberbanding), disturbing visual side-effects of UDP position updates are minimized.

6. As combat progresses, incremental UDP-based movement vector corrections steer Client simulation to converge on Server's player and enemy positions, reducing the need for abrupt resynchronization of Client simulation.

7. If any part of the UDP update process fails at any time, Client ignores it and continues to use the current TCP-based simulation system.

"

RogueMage wrote:

Yes, this is what Scrotie proposed months ago

Dont suppose you have a link?

"

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.

"

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.

Minor overhead savings and major savings in the fact you dont have to wait for lost packets to be resent(tcp requires things in order, so even if youve gotten the next packet you still have to wait for the last packet to be resent and received before you can use it). Considerably faster overall and reduces network congestion slightly in comparison to tcp.
Think of it like this, in udp if shit goes sideways you are just denied that singular packet.
But in TCP, if shit goes wrong you can have some serious issues as basically the entire socket is imprisoned waiting for that lost packet. But the strict order and reliability of tcp often makes it worth it. These factors are very desirable for people who dont want to have worry about such scenarios where data comes in out of order or even not at all. A lot of ppl who attempt to use udp end up hand coding what basically amounts to tcp over udp, and are left with the realization they just wasted a fuckload of time.
You could say UDP is strictly better than tcp.
But tcp is highly tuned by some very smart ppl. And if you need the benefits of what tcp offers, it beats hand coding it yourself. Unless of course you are a super genius and can surpass TCP's performance.
The ultimate answer could be neither though. If you dont need to send or receive data, dont.

"

SkyCore wrote:

Minor overhead savings and major savings in the fact you dont have to wait for lost packets to be resent(tcp requires things in order, so even if youve gotten the next packet you still have to wait for the last packet to be resent and received before you can use it). Considerably faster overall and reduces network congestion slightly in comparison to tcp.

I know what the advantages of UDP are. I don't see a reason to use TCP for games in general, considering that input is inherently asynchronous anyway

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.

The server it'self will be very vulnerable to this.

It's also worth noting that the majority of traffic between these two endpoints consists of packets ~68 bytes in length.

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

Another concern, although I freely admit I've not researched this fully, is that 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.

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, is far worse then a bit of network overhead.

Have a look at UDP hole-punching to see what I'm getting at.

For example, there are large swathes of Europe that are behind a NAT at a national level; Russia is a good example of this.

"

genericacc wrote:

"

SkyCore wrote:

I know what the advantages of UDP are. I don't see a reason to use TCP for games in general, considering that input is inherently asynchronous anyway

While that may be an interesting digression, it's not one of the issues we've been discussing in this thread. PoE has already been implemented using TCP, debugged, and tested over a long period of time. I think everyone here would agree that abandoning that implementation in favor of something not yet developed or tested would entail far more time, expense, and risk than GGG or PoE can afford.

In my view, one of UDP's most compelling advantages is the prospect of adding an independent, high-speed, completely optional and triageable position update stream requiring virtually no risk or revisions to the current TCP-based simulation system.

"

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, is far worse then a bit of network overhead.

I dont believe anyone is suggesting that the secondary channel be mandatory nor always on.