[1.1.61] Error connecting to server: "TransferTarget threw an exception on stopDownload: CRC mismatch"
Posted: Wed Jun 29, 2022 9:40 am
What did you do?
Tried to connect to multiplayer server approximately 100 times in a row. Also, another player outside my home took dozens of attempts before a successful connection.
What happened?
The server saves the map to it's temp directory. Then begins transmitting it to the client. When the transmission is complete the client tries to load the downloaded multiplayer save from it's temp directory, but fails because there are CRC errors for some number of files in the downloaded zip file.
What did you expect to happen instead? It might be obvious to you, but do it anyway!
As stated in the wiki https://wiki.factorio.com/Multiplayer "The game builds its own "reliable delivery" layer built on UDP to deal with packet loss and reordering issues." I expected that even during the download phase this would ensure a proper and complete uncorrupted transfer. Then that the client would load the save and join the game.
A lot of discussion and troubleshooting on stream was done. https://www.twitch.tv/videos/1517293921?t=00h27m32s
I have attached the log and the temp save from the server (mp-save-142.zip) and also the corrupted save transferred to the client (mp-download.zip).
Network topology is my server is running in a docker container under unRAID connected to the main WAN switch (which is the path to the ISP that my friend finally received a good file) and another switch that connects to my PC. During testing I even switched which network port I used on my PC.
IMHO I think something is happening with the UDP connection and the logic to make sure it's robust is failing somehow. The zip file from the server is perfectly fine and playable. The file that shows up in the client temp folder though has CRC errors on up to multiple files running a test with 7zip. Both files do have the exact same file size though.
Please note this isn't a desync issue, the downloaded map itself is corrupted.
In another thread kovarex stated that this could happen "very rarely" but this is fairly repeatable in this instance. I would be happy to PM server password to staff.
Tried to connect to multiplayer server approximately 100 times in a row. Also, another player outside my home took dozens of attempts before a successful connection.
What happened?
The server saves the map to it's temp directory. Then begins transmitting it to the client. When the transmission is complete the client tries to load the downloaded multiplayer save from it's temp directory, but fails because there are CRC errors for some number of files in the downloaded zip file.
What did you expect to happen instead? It might be obvious to you, but do it anyway!
As stated in the wiki https://wiki.factorio.com/Multiplayer "The game builds its own "reliable delivery" layer built on UDP to deal with packet loss and reordering issues." I expected that even during the download phase this would ensure a proper and complete uncorrupted transfer. Then that the client would load the save and join the game.
A lot of discussion and troubleshooting on stream was done. https://www.twitch.tv/videos/1517293921?t=00h27m32s
I have attached the log and the temp save from the server (mp-save-142.zip) and also the corrupted save transferred to the client (mp-download.zip).
Network topology is my server is running in a docker container under unRAID connected to the main WAN switch (which is the path to the ISP that my friend finally received a good file) and another switch that connects to my PC. During testing I even switched which network port I used on my PC.
IMHO I think something is happening with the UDP connection and the logic to make sure it's robust is failing somehow. The zip file from the server is perfectly fine and playable. The file that shows up in the client temp folder though has CRC errors on up to multiple files running a test with 7zip. Both files do have the exact same file size though.
Please note this isn't a desync issue, the downloaded map itself is corrupted.
In another thread kovarex stated that this could happen "very rarely" but this is fairly repeatable in this instance. I would be happy to PM server password to staff.