[cube]Multiplayer crash on connect and UDP packet spam

[Cyberdragon]

I am no longer able to play multiplayer anymore because it crashes (freezes) when downloading a multiplayer map from a server. I've tried using a network limiter to slow down the connection but it still crashes. From what I can see with Wireshark, the transfer starts normally and goes until the sent UDP packets start rapidly exceeding the received packets at which point it gets frozen. Then it keeps going until there are no more received packets then keeps going until it DOS's your connection and your router crashes. (it recovers almost immediately after closing the game through task manager). However, it does not say it has been disconnected (or do anything else, just a stuck downloading bar) until you disable your internet, then you get the connection lost screen and can properly close the game.

This produces no crash logs but spams this in the main output log.
Info TransferTarget.cpp:242: Received transfer block [random #s here] that we didn't request from peer 0

You can try to fix the current system, but I highly recommend you stop using UDP to download anything. This is not how you use UDP, because if you drop even one packet, the above could happen. UDP is ok over a LAN, because the likelyhood of dropping packets is small. But please use proper TCP for downloading maps now that there are servers on the internet where packets could get lost.

EDIT: And yes I am talking about 0.12.4.

[daniel34]

Related posts:
Same problem: https://forums.factorio.com/forum/vie ... 49&t=15190
and his own https://forums.factorio.com/forum/vie ... 49&t=15145

From your posts in Bisas dedicated server thread (https://forums.factorio.com/forum/vie ... 988#p99988) I can see that you've been able to play in multiplayer before.
Did you have problems then or did you change anything since then?
What is your configuration (OS, Internet connection/speed, Router/NAT, wlan/ethernet/hamachi/...)?

little bit OT:
I'll agree with you that in an server-client environment TCP should be used, but Factorio is P2P over UDP currently and switching off the P2P option just routes your packages through the server.
Nonetheless, I'm sure they tried to control/limit the UDP traffic so it works like TCP traffic (requesting ACKs for every downloaded packet, don't send a lot of packets without reply, ...)
Seems the problem lies somewhere there.

Ideally Factorio would use TCP for the connection:

• It's less taxing on the internet connection, especially with a lot of packets (I only get 200-400kb/s map download with UDP while TCP gives me full 650kb/s bandwith)
• manages bandwith better (currently, lags happen when anyone on the server downloads something, even limited to low speeds)
• you don't need to open any ports (steam release --> "why do i need to open port ...")
• server is in control of the gamestate (server can't be dropped)
• an actual dedicated server just sends relevant packets to me / vice versa
  I've seen servers that work with 6 clients but lagged with 7, no matter who joined
  Reason: one client has bad upload speed and can't get out enough heartbeats/pings
  I'd approximate that every new client taxes your own internet connection with an additional 4-5kb/s up and down, and someone with a 256kbit upload connection can effectively limit the amount of players on the server.

Of course I understand that there are some disadvantages using TCP (packets need to go through server, TCP packet overhead with ACKs/other packets) but I think it would be more stable and controlled with something like that.
(was more OT than I thought, I might move that to a separate topic)

[cube]

This is probably the same problem than the posts that daniel34 linked (and also as several bug reports marked as resolved now -- this bug has been here for a long time :-) ).

[Cyberdragon]

IDK why it stopped working now in 12.4, but its most definitely because UDP is being used incorrectly. Requesting the packets on UDP is useless and actually BAD, because they really don't even work on UDP so if a packet is actually dropped the requests are not at all able to recover it and just spam trying to do the impossible. I guess we have been getting lucky and not dropping packets.

There might be a really dodgy way of getting a semi-reliable (not really, just stupid) data transfer on UDP but it will make it snail slow. That would be to send the same set of packets a few times then move on to the next set. The host program would simply delete the repeats, so if a packet is dropped it may get it on the next send. However it will still crash if it does not get all the packets in the set after the allotted repeats.

[SirRichie]

Aware of the danger that I might sound like a wise-ass, but I still need to correct (as I think) a few things that have been said here, because it seems that there are a few misconceptions about what UDP and TCP do:

UDP and TCP are very similar and work almost in the same way, both building on top of IP. The difference is that TCP guarantees packet delivery and that packets arrive in the correct order. UDP makes no guarantees. TCP achieves that by sending acknowledgements for packets. This causes overhead, which is why in a lossless environment, UDP can achieve more throughput. Any application can of course emulate TCP's acknowledgements when using a UDP connection, but since these are then handled in the application layer instead of the network layer, this is slower than just outright using TCP.
This of course is a very simplified overview, there are a lot more tradeoffs to make, TCP has multiple modes etc.
There are many, many articles about this on the Internet, one related to gaming is http://gafferongames.com/networking-for ... dp-vs-tcp/

What does this mean for the statements given here?:

I'll agree with you that in an server-client environment TCP should be used, but Factorio is P2P over UDP currently and switching off the P2P option just routes your packages through the server.

TCP and UDP are protocols, client-server and peer-to-peer are communication models. You can freely use one with the other. You can very well use a client-server model with UDP, and in fact this is what most modern FPS games do.

Nonetheless, I'm sure they tried to control/limit the UDP traffic so it works like TCP traffic (requesting ACKs for every downloaded packet, don't send a lot of packets without reply, ...)

Limiting UDP traffic does not make it work like TCP. Users cannot do anything on their machine, it has to be done in the code.

It's less taxing on the internet connection, especially with a lot of packets (I only get 200-400kb/s map download with UDP while TCP gives me full 650kb/s bandwith)

For the reasons pointed out above (and also in the article), TCP is more taxing on the internet connection, unless you have a very high rate of packet loss (>10%). If you see more bandwidth use, this may be vey well because TCP actually requires more bandwidth. OR that the game emulates some TCP features on top of UDP and does this in a poor way.

manages bandwith better (currently, lags happen when anyone on the server downloads something, even limited to low speeds)

This is somewhat true. TCP has flow-control, but that only works between any two computers. The observed behavior is more likely to be caused by synchronization between already connected and the soon-to-be connected client. TCP does not have a group flow-control.

you don't need to open any ports (steam release --> "why do i need to open port ...")

I am sorry, but this is plain wrong. Both TCP and UDP use ports for splitting up a single IP connection.

server is in control of the gamestate (server can't be dropped)

Has nothing to do with TCP or UDP, it is a property of the communication model, see above

an actual dedicated server just sends relevant packets to me / vice versa[...]

Again, this is no issue of TCP or UDP. You're talking about multicast vs. singlecast vs. broadcast. Any of these work with TCP and UDP. The observed behavior is more likely due to a less-optmized implementation than TCP or UDP use.

IDK why it stopped working now in 12.4, but its most definitely because UDP is being used incorrectly.

Or because of the new communication model. But I agree, UDP is easy to be used in a wrong way.

Requesting the packets on UDP is useless and actually BAD, because they really don't even work on UDP so if a packet is actually dropped the requests are not at all able to recover it and just spam trying to do the impossible.

This is untrue. As mentioned, many modern, AAA FPS shooters use UDP. The problem is that if you want a connection model or resend lost packets, you will have to implement this on your own with UDP. It is easily done wrong, but using UDP is not generally a bad idea. Also, you do not request packets. Both protocols send packets. Sometimes in response to a request. This may seem picky, but the important thing is that TCP/UDP are the communication protocol. Requests and responses are part of the application's communication model.

There might be a really dodgy way of getting a semi-reliable (not really, just stupid) data transfer on UDP but it will make it snail slow.

https://en.wikipedia.org/wiki/UDP-based ... r_Protocol


Now that said, I am not particularly a fan of UDP. It has advantages, especially in gaming, but TCP is a much easier option to use. I just wanted to clarify what appeared to me as misconceptions of UDP and TCP.

[Cyberdragon]

I have updated to 12.5. Nothing has changed, it's still broken. I wonder why? -_-

[cube]

Should be fixed for 0.12.7 :-)