Do bears shit in the woods?

[SeraphimLeftNut]

Only if acknowledged by the forest floor.

How orders are lost

All the orders given by a player are sent to the opponent in UDP packets, to be confirmed as received with acknowledging UDP packets.

Once the order is acknowledged it is run on both systems running the game, 500 ms after the original order issuance. (net_LAG parameter)

If acknowledgement takes longer than 500 ms from the issuance of the order, then sim stops and waits. (This causes stutter and other wonderful issues related to ui lag, although on an ideal system the ui should not sense such an event)

Given that UDP packets tend to get lost, the game will try to resend the orders 3 times before cancelling the order.(I saw this 3 number in a message board post by one of the devs, don't have the link saved)

The rate at which the orders are resent is determined by the following parameters: net_MaxResendDelay, net_ResendPingMultiplier, net_ResendDelayBias, net_MinResendDelay.
The wiki lists the equation for the delay as ping*new_ResendPingMultiplier+net_ResendDelayBias. However, I vaguely remember(once against from that forum post) that the equation is more complicated and the later resends occur more rapidly.
An upper bound on how long it will take the game to lose orders is (ping+25)*3 ms. A corrolary to this is that orders that take too long to get to the destination will not be acknowledged, in order to avoid the situation where the sending system cancels the order, while the receiving/acknowledging one takes it seriously.

You can see that ping jitter will make this a very crazy situation.(you can let your imagination run wild here...)

A major source of upstream traffic delay is bufferbloat. Caused by shitty isp's. https://youtu.be/0hzxwoZDI9s?t=41

When the connection is under load uploaded traffic can be delayed for 1+ seconds (my case). This means BITS, windows update, firefox, FAF, a wardriver, etc. can indirectly cause your orders to disappear.

Furthermore all this can have a very interesting effect on orders such as, the attack move into space, patrol order, assist order,..

These orders are not specific to an action, so when an engineer wandering around setons clutch wants to reclaim a rock, it needs to ask everyone's permission first and if that permission doesn't come, it will need to wait and choose another rock.

How about an effect on targeting entities that adjust their path...

[justmakenewgame]

long story short #FAremake

[RocketRooster]

long story short #FAremake

The fundamental issue remains no matter what you do - latency over the internet. UDP is used for peer to peer because the minimum packet sizes are smaller than TCP, multicast is possible and so an ack-based pseudo-connection-state is created at the application layer. But it remains best effort comms and rewriting FA cannot change the fact that compromises have to be made due to the underlying networking model of the internet which is a mishmash of circuit switching and many potential points of failure in the context of having responsive realtime comms. You could use TCP but then generally you'd use a central server as the hub for comms between clients, alternatively you'd need a stateful socket between every peer in the game. Consider the event of a socket being dropped - the game would halt for everyone while the two peers with the dropped socket renegotiate the connection. Dropping command packets is a much better compromise.

The GPG networking programmers aren't amateurs, they knew what they were doing. Rest assured that they investigated every option and settled on the best solution.

[SeraphimLeftNut]

long story short #FAremake

The fundamental issue remains no matter what you do - latency over the internet. UDP is used for peer to peer because the minimum packet sizes are smaller than TCP, multicast is possible and so an ack-based pseudo-connection-state is created at the application layer. But it remains best effort comms and rewriting FA cannot change the fact that compromises have to be made due to the underlying networking model of the internet which is a mishmash of circuit switching and many potential points of failure in the context of having responsive realtime comms. You could use TCP but then generally you'd use a central server as the hub for comms between clients, alternatively you'd need a stateful socket between every peer in the game. Consider the event of a socket being dropped - the game would halt for everyone while the two peers with the dropped socket renegotiate the connection. Dropping command packets is a much better compromise.

The GPG networking programmers aren't amateurs, they knew what they were doing. Rest assured that they investigated every option and settled on the best solution.

The UDP packets coming from my FA have DSCP value of 48(checked with wireshark). This was set using QOS settings, there is a thread about this.

[RocketRooster]

Well it looks like you're in the fortunate position that your ISP honours it judging from your improvement. Have you tried getting it to 46 (iirc the most critical priority value)?

I'm smelling me some usefulness of writing some sort of middleware running on the local machine that diddles with the headers. Or hacking gateway firmware. Hmm......

[SeraphimLeftNut]

Well it looks like you're in the fortunate position that your ISP honours it judging from your improvement. Have you tried getting it to 46 (iirc the most critical priority value)?

I'm smelling me some usefulness of writing some sort of middleware running on the local machine that diddles with the headers. Or hacking gateway firmware. Hmm......

Please make this and share it with all the noobs.

[nine2]

Pretty sure the middleware is already there
'the proxy'

[RocketRooster]

Proxies generally concern themselves more with presentation and session layer data while ignoring the transport layer stuff, but I stand to be corrected.

I've given the middleware idea a bit of thought and I retract the notion. I am not sure it's worthwhile. For one thing, essentially it would have to simulate FAF netcode, i.e your FAF would communicate with it, while it in turns communicates with the middleware at the peer, which communicates with the peer's FAF. This will add some latency in of itself, and even if all it did was ensure that the FAF traffic was tagged as time critical, it still doesn't guarantee that you ISP will honour the header settings. So it's no improvement on hacking registry settings, infact it would likely be slightly worse.

[d-_-b]

if you are choking your upstream to the point where packets are delayed, probably you should kick people off netflix... ISPs rarely respect any headers, and more likely to do their own traffic policies based on DPI. If your neighbours are choking the ISP's links there is nothing you can do.

OR put some firmware on your router that can do QOS, so at least they are not being choked by some up/download locally.

a token bucket on udp traffic on faf port from your computer with higher priority etc, will work wonders on a choked line. you could even torrent and it wouldn't impact your game.

DD-WRT can do this, no problem.

the software that comes with home routers is notoriously shit.

FAF requires about 40KB/s UP and DOWN to do 6v6.

Also, you can make sure that your packets are not being fragmented by calibrating your MTU. Classic example of a DSL line running PPPoA, the ethernet sends packets of 1500 bytes tops, but once they get sent down your dsl line, the atm headers steal bytes from that, so your 1500 byte packet gets fragmented into two packets, which can of course take different routes/be delayed by different amounts for various reasons etc...