Technical solution to eliminate desync in single-player sessions

"

Skogenik wrote:

"

Sachiru wrote:

It's not the server generating the FCS, it's your router.

Any time data is transmitted somewhere along the line that has an incorrect FCS, it's dropped. If this occurs on the server, the network switch it's connected to will drop the frame and you won't receive it to begin with. The fact that you can detect the frame transmit error means that it's on your last hop/link.

EDIT: Note that this is an ethernet frame encapsulating, and not a tcp/ip packet. As such, the "source" is considered to be the source MAC address, not the source IP. IP is used for end-to-end relay of data, ethernet for next-hop relay.

If you're going to cite Wikipedia, I'll just paste in the relevant bit from the same article:

"

wikipedia wrote:

All frames and the bits, bytes, and fields contained within them, are susceptible to errors from a variety of sources. The FCS field contains a number that is calculated by the source node based on the data in the frame. This number is added to the end of a frame that is sent. When the destination node receives the frame the FCS number is recalculated and compared with the FCS number included in the frame. If the two numbers are different, an error is assumed, the frame is discarded. The sending host computes a checksum on the entire frame and appends this as a trailer to the data. The receiving host computes the checksum on the frame using the same algorithm, and compares it to the received FCS. This way it can detect whether any data was lost or altered in transit. It may then discard the data, and request retransmission of the faulty frame.

And here we have definition errors.

For ethernet, the source node is defined as the previous-hop device that the packet comes from. A bit of checking would easily reveal that the MAC address marked as source address on your packet would reveal the MAC address of your default gateway - does that mean that your default gateway is the GGG server? I don't think so.

And, yet again, to quote what you quoted:

"

When the destination node receives the frame the FCS number is recalculated and compared with the FCS number included in the frame. If the two numbers are different, an error is assumed, the frame is discarded.

If the packet is invalid from the source (as in from the GGG server), the moment it gets to the switch/router/whatever intervening device is there, it gets discarded. You don't see it.

Please do not confuse ethernet source node with source IP address. Ethernet is used for next-hop determination, not for end-to-end routing.

Hi ScrotieMcB; Thanks for your feedback - it's 4am in the morning here, so I'll try and consume this later, properly.

One thing that I do note though, so I want to just clarify the point your made:

"

ScrotieMcB wrote:

TLDR: Pretty much every outgoing packet is going to trigger a checksum error in Wireshark.

I'm asking, because in my case - it was 61% of incoming packets that were failing, outgoing faults were non-existent in the sample I took.

I too noticed a few out-of-order ACKs that were marked as bad, they were periodic but relatively predictable.

I'll run some more sampling tomorrow, but perhaps sharing logs and comparing could be useful?

"

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. However, I anticipated this issue and designed the UDP update system to use an asynchronous, non-critical stream that can be suspended and resumed at any time, as needed. That allows the server to use a variety of metrics to determine when it can afford to support UDP broadcasts. 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.

"

Sachiru wrote:

If the packet is invalid from the source (as in from the GGG server), the moment it gets to the switch/router/whatever intervening device is there, it gets discarded. You don't see it.

Yes and no; it's not quite as simple as you're seeing it.

The FCS may or may not be calculated in Hardware; but the point is, as far as the Internet is concerned - your router is *just another hop*.

The only thing that will drop the frame is the receiving node, and that node (in this case) is the network card in the back of my machine.

Now, as you've pointed out - it's not the Hardware layer layer that creates this checksum, it's the data layer and that is implemented by the NIC driver on your computer; *not* the hardware unless you're using one of those accelerated NICs; this is done in a part of the driver called the Protocol stack.

So, I do see it (the bad packet) - the bad frame comes in, and my NIC driver decodes the frame, realises the CRC is bad and rejects it; or it normally does so.

The reason why it doesn't in this scenario is because of the WINPCap driver that Wireshark uses.

One again, Hops don't interpret FCS' and there are a few good reasons for this.

In this scenario though, the primary reason is that the target needs to know it received a bad packet so that it can know which Sequence and ACK chain it's following. If a Hop rejected a packed because it's FCS was wrong, the server would have to say, oh that's wrong but I can't reuse that sequence and ack, so here's a new one. And now, the target gets the new packet and doesn't recognize the sequence and drops it as an out-of-sequence/band/etc packet.

Look, I'm not trying to argue with you - this is for the benefit of everyone who plays this game; but don't sit there and try and tell me that 61% of the packets my computer processes are wrong because of a local fault; because I can prove that this is *not* the case.

Perhaps you could see your way to trying to perform the same tests that I have, more evidence on this matter would be awesome; I am preprared to believe that it's just the node I was connected to, but if there's a chance that it isn't - we might be on to something that will get this game sorted.

The simplest answer tends to be correct. GGG fucked up at the beginning and were unwilling to unwrap it. This game is going to be sold in 2014 to a company willing to make the difficult changes, or the game will be completely dead in 2015.

"

Skogenik wrote:

"

Sachiru wrote:

If the packet is invalid from the source (as in from the GGG server), the moment it gets to the switch/router/whatever intervening device is there, it gets discarded. You don't see it.

Yes and no; it's not quite as simple as you're seeing it.

The FCS may or may not be calculated in Hardware; but the point is, as far as the Internet is concerned - your router is *just another hop*.

The only thing that will drop the frame is the receiving node, and that node (in this case) is the network card in the back of my machine.

Your computer is not the only "receiving node".

To quote from the IEEE Ethernet Standard, Section 1, pages 556-557.

"

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, it passes the Destination Address (DA), the Source Address (SA), the Length/Type, the Data, and (optionally) the Frame Check Sequence (FCS) fields to the MAC client, along with an appropriate status code, as defined in 4A.3.2. It also checks for invalid MAC frames by
inspecting the FCS to detect any damage to the frame enroute, and by checking for proper octet-boundary alignment of the end of the frame. Frames with a valid FCS may also be checked for proper octet-boundary alignment.

MAC frames are checked on each station to prevent errors propagating across the internet, otherwise a single client which transmits polluted frames will pollute every single hop it crosses across the internet. Over time and given a sufficient number of clients that are transmitting bad data, the internet would become a cesspool of garbage.

It would make more sense to filter bad data at the point of entry rather than letting it travel across the entire internet and filter it out only at the point of exit.

"

Skogenik wrote:

One again, Hops don't interpret FCS' and there are a few good reasons for this.

In this scenario though, the primary reason is that the target needs to know it received a bad packet so that it can know which Sequence and ACK chain it's following. If a Hop rejected a packed because it's FCS was wrong, the server would have to say, oh that's wrong but I can't reuse that sequence and ack, so here's a new one. And now, the target gets the new packet and doesn't recognize the sequence and drops it as an out-of-sequence/band/etc packet.

Or, a more sensible solution would be to retransmit the previous ACK. No need to change sequence numbers, because sequence numbers only increment on successful reception of ACKs, otherwise retransmission would not work.

Seriously, read Wendell Odom's book on LANs. It's an easy enough primer to TCP/IP communications.

It's practically common knowledge to network engineers that FCS errors are caused by link-level/interface problems. It's common and it happens to Wireless and wired, and it's a testament to the resilience of TCP/IP that despite a high error rate things still work relatively well. Ask any network engineer about FCS errors, and the first thing he'll ask you is if it's wired or wireless, and if your wires or interfaces are working fine and without noise/crosstalk.

"

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.

"

Sachiru wrote:

It's practically common knowledge to network engineers that FCS errors are caused by link-level/interface problems. It's common and it happens to Wireless and wired, and it's a testament to the resilience of TCP/IP that despite a high error rate things still work relatively well. Ask any network engineer about FCS errors, and the first thing he'll ask you is if it's wired or wireless, and if your wires or interfaces are working fine and without noise/crosstalk.

I'm sorry to labour the point once more; but again - I've only encountered this problem when communicating with the PoE servers.

Trust me, the only thing that's different between now and when I did my MCSE+TCPIP is the focus on IPv6.

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.

I think people got the gist of your opinion from your first post already, poeticheretick.