Extensive lag may cause disconnections

[scythetwirler]

It seems that extensive lag may cause disconnections (sometimes even the host is disconnected from himself).

If there is a connection timeout, can that be extended?

[scythetwirler]

This can be pushed to A18, but if it can be reduced by changing a constant, then I think that would be an acceptable last-minute "fix".

[historic_bruno]

What is causing the lag? That sounds like the big issue.

[elexis]

I also experienced this sometimes when the game was laggy and a ship sunk (see sunken ship lag fix r16636). Then I lost the connection to the server although I was the host. I assume that the local client was disconnected from the server due to a timeout. This timeout might be changed for the local client using enet_peer_timeout.

---

Replying to historic_bruno:

What is causing the lag? That sounds like the big issue.

There are many things that can cause those lags / performance issues.

---

I don't think that the timeout for the other clients should be increased though. The causes of the lag must be addressed. I actually think that the timeouts should be decreased, since one waits for up to 30 seconds (ENET_PEER_TIMEOUT_MAXIMUM = 30000) for clients and people lose the interest in the game meanwhile, see #3264.

[elexis]

As mentioned in #3423, the solution to the problem of the host being disconnected from itself should be to not have a timeout at all for the client that the host uses. Another example for a 30 second timeout is the harddrive going into standby mode and not coming back quickly enough.

The other client timeouts should be handled in #3264.

[elexis]

Workaround: The local client is disconnected from the server. But the server isn't closed until one clicks on the exit-game button. It is possible to rejoin the crashed game with a second instance of 0 A.D.

[elexis]

In 17772:

Prevent the local client of the host from becoming disconnected in case of lag, fixes #2854.

[elexis]

The local client of the host actually became disconnected after a 5 second timeout (since the latency from 127.0.0.1 to 127.0.0.1 is excellent (16ms) and it would disconnect it after a multiple of this time, but not before 5 seconds (see ​http://enet.bespin.org/group__peer.html#gac48f35cdd39a89318a7b4fc19920b21b)).

Having a 5 second timeout is really easy with an HDD coming back from standby mode.

To reproduce this type of disconnect on linux, just simulate an arbitrary timeout:

function setlag()
{
	for device in "lo"; do
		sudo tc qdisc del dev $device root netem;
		if [ $1 -ne 0 ]; then
			sudo tc qdisc add dev $device root netem delay ${1}ms;
		fi
	done
}

[elexis]

In 17960:

enet backward-compatibility fix, refs #2854. Patch by texane, fixes #3863.

[elexis]

In 18140:

Network cleanup, fixes #3953.

Don't compare for "127.0.0.1" to identify the host, but check for a new boolean flag that is set by the client, refs #2854.
Remove an unneeded IP address conversion from u32 to string, refs #3241.