[0.17.52] Long /silent-command lead to dropping players

[Hornwitser]

There's currently a clusterio event that's being tested that uses train teleportation to transfer items between servers. It uses scenario modding and automated server commands to accomplish this. The test server I'm able to reproduce this problem with is called [Gridlock Test Cluster] Westeros. When I place a trainstop such that it synchronizes the the trainstop list (i.e., in the top right of the map) the client freezes and the Server Not Responding dialog appears and stays until the connection is dropped. From the server side it's most of the time reported as the client can't keep up. Not everyone that connects to that server experience this issue.

Looking at a packet trace with Wireshark I can see that it sends a long /silent-command (of about 18k characters) over and over again. The network traffic doesn't stop while the Server Not Responding dialog is up. There's packets going both from the server to the client and from the client to the server, and there's packets coming from the server long after the client has given up. There's no significant CPU usage while this happens, and there's no significant amount of network traffic being sent.

The factorio-current.log is full of entries like this:

Code: Select all

12555.292 Info UnparsedNetworkMessage.cpp:91: Invalid packet (type ServerToClientHeartbeat) received from IP ADDR:({94.237.93.212:5000}): heartbeat sequence number (271096) outside latency window [270296, 271096)

They seem to be a red herring as they are reported long after the the not responding dialog has appeared.

Attached is a logfile with a corresponding packet trace from Wireshark.

[psihius]

Paging @Twinsen
You have dealt with that issue of long packets last time, maybe you can take a look at this?
Seems like network packet encoding issue, this time on way longer strings

[Oxyd]

Thanks, fixed in 0.17.53.

[psihius]

Yay, thank you!
Would be interested in what was causing it here or maybe upcoming FFF?

[Oxyd]

Eh, nothing terribly exciting. It was simply trying to send the entire command in a single network message. We have a mechanism to split actions into multiple messages (so they get sent over multiple in-game ticks), but it wasn't being used for RCON commands.

[psihius]

Hehe, thanks for the explanation, we keep breaking your game with "valid" usage