Technical solution to eliminate desync in single-player sessions

"

RogueMage wrote:

"

ScrotieMcB wrote:

This isn't about idealism, it's about practicality. Using both protocols for continuous transmission isn't practical, because it isn't economical with bandwidth.

I don't think either of us is in a position to make blanket judgments on how much bandwidth GGG can afford, nor can we accurately ballpark the amount of bandwidth a minimalist UDP stream would require.

Fair enough, but I am inclined to believe that my estimate of "GGG didn't have enough bandwidth to support all users immediately after release, and then got enough bandwidth to barely support them in terms of merely keeping the connection up, preventing disconnects" is fairly reasonable.

"

RogueMage wrote:

In the event that the UDP update stream fails to reach the client for any reason, it will simply revert back to working as an open-loop simulator, just as it does today.

No offense to GGG, but the current system is mediocre at best. And that's putting it nicely; I'm half-tempted to agree with heretick here. (Except for the laughing part; no one's laughing.)

"

ScrotieMcB wrote:

No offense to GGG, but the current system is mediocre at best. And that's putting it nicely; I'm half-tempted to agree with heretick here. (Except for the laughing part; no one's laughing.)

I've been deliberately trying to provoke it into resync lately, just to get a feel for its limits, and I'm not sure what to conclude. I can easily get it to resync by charging through trash mobs with Cyclone or Whirling Blades, but if I play conservatively and don't try to cover too much ground, I can stay safely below the resync threshold. When soloing, however, I tend to play slowly and cautiously, and that may not provoke as much desync as more aggressive styles of play.

I suspect many of the most vehement complaints about desync have come from high-level players who want to farm areas as quickly as possible, using massive firepower to faceroll mobs while moving relentlessly forward. While that's certainly a legitimate playstyle, it's probably more amped-up than most players can sustain at their character's area level. With unrestrained movement speed, however, GGG may just have to resort to capping it for the game's own good.

"

Skogenik wrote:

"

Sachiru wrote:

At each receiving station...Receive Data Decapsulation checks the frame’s Destination Address field to decide whether the frame should be received by this station. If so, i...

Highlighted the salient part. A node directing a packet isn't a node that has to receive that packet, it's just a node that routes it.
Why? Because the Packet doesn't care how or where it's transmitted, only that it's received by the device matching the MAC address of the destination.
Once that's out of the question, the nodes job is to simply forward the packet.

If it were any other way, someone could write rogue software that could just man-in-the-middle any packet on the 'net by simply responding to all requests saying, thanks I got this; when it's routed through.

I suggest that you retake your MCSE+TCPIP, since you clearly did not understand the material.

Ethernet was not created originally with switches, in the grand old days, we used hubs. As such, EVERYONE on the wire received packets sent, that's why you have MAC addresses, this is to help all receivers know if they're the ones being talked to.

And yes, back in the days of hubs, there WAS software and hardware that did man-in-the-middle interception like you talked about. Google "promiscuous NIC".

To repeat my point: Bad frames originating from the server die at the first switch. As proof:

Cisco

"

Frames Discarded Upon Ingress (From the User Device to the Network):

...
7. Frame CRC error Port CRC errors (P 0x06 Receive Frame CRC Errors, also increments C 0x03 & C 0x0C @ egress)
...

You seem to misunderstand the difference between frames and packets. A Packet will not have the source IP/Destination IP pair change at any point during transmission (except if it passes through a device that implements NAT), however the source/destination MAC address pairs change as it traverses the internet. Try it, do ARP lookup on your local machine for public IPs, such as 8.8.8.8 (Google DNS) or 208.67.222.222 (OpenDNS). It'll show you the MAC address of your default gateway as your destination, because it gets rewritten the moment it exits your router. MAC addresses are for next-hop resolution, IP for end-to-end.

Just wanted to but into your guys' conversation real quick to point out that

"

Sachiru wrote:

except if it passes through a device that implements NAT

is a little disingenuous because pretty much every client-to-server route will implement NAT at the residential router level; you can assume it will occur. Otherwise, Sachiru's explanation is pretty spot-on.

Yes I'm being nitpicky.

"

deteego wrote:

"

SkyCore wrote:

Im not suggesting that udp streaming magically removes desynching. All im saying is that it corrects desynch at regular intervals just as /oos does. Its not perfect. But its easy to imp and its an improvement.

What do you mean by 'regular', any kind of regular /oos is going to look like stagger whenever it happens. You need to define what you mean by regular, because if its just an /oos that happens every 2 seconds, then that isn't much better than using a macro that does /oos every 2 seconds (at least from a user pov)

By regular i mean 'often'. Variable rate would prolly be the best way. As the server has extra bandwidth to spare it pulses more often with less delay in between .
As for it not being better than /oos spam, you are wrong. For one it wouldnt require user action(or use of a macro). Also it would reduce the response time of the macroed oos by half a ping. But primarily it would benefit from udp, gaining speed and reducing network trafic. And dont forget that if each player is spamming /oos it may overload the servers network, something this design resolves.
And i have mentioned solutions to 'staggering' several times, which is a separate issue in my mind as i care about the true positions of things more than visual ascetics. But of course the masses are suckers for fluff so its not entirely irrelevant.

"

poeticheretick wrote:

GGG is laughing their ass off. All the posts they have made on this thread prove they have given up on the desync issue LONG ago. Yet you all persist thinking otherwise.

They still say that they are working on it. ;)

"

They still say that they are working on it. ;)

When did they say that? They haven't made any posts saying they are working on it or that they even have plans to work on it.

"

qwave wrote:

"

They still say that they are working on it. ;)

When did they say that? They haven't made any posts saying they are working on it or that they even have plans to work on it.

http://www.pathofexile.com/forum/view-thread/575351/filter-account-type/staff

Worth getting this back in the front page.

http://www.reddit.com/r/pathofexile/comments/1u1lyq/some_facts_and_details_about_desync_sparked_by/