![](https://attach.openclonk.org/avatars/572-36568.png)
![](https://attach.openclonk.org/avatars/336-99322.png)
![](https://attach.openclonk.org/avatars/65-0196.png)
Depends on what the root problem is - if it's too much data, increasing the control rate could improve things. If it's about package losses, disabling UDP in the options could make a difference.
Does our network switch to TCP if UDP isn't working fine?
Btw, what good is UDP doing? We ensure reliable in-order transmission anyway. Circumventing the flow control of TCP?
Btw, what good is UDP doing? We ensure reliable in-order transmission anyway. Circumventing the flow control of TCP?
![](https://attach.openclonk.org/avatars/65-0196.png)
Originally, the idea was to support multicast - which is the only way to make the whole thing scale without a dedicated server. Sadly it was a bit too optimistic to think that providers would allow it.
These days, its benefit is mainly that there are some router configurations that UDP can get through but TCP can't. Also it's pretty nice to have two connections while data is transferring - it means that you can chat without delay while, say, the scenario is loading. As long as there's no packet loss, it is also slightly faster (as in: more responsive) reportedly.
These days, its benefit is mainly that there are some router configurations that UDP can get through but TCP can't. Also it's pretty nice to have two connections while data is transferring - it means that you can chat without delay while, say, the scenario is loading. As long as there's no packet loss, it is also slightly faster (as in: more responsive) reportedly.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill