Will TCP really affects UDP if used in different context?

Question

I have read some questions about using both TCP and UDP in multiplayer game, such as Does it make sense to use both TCP and UDP at once? and Is UDP still better than TCP for data-heavy realtime games?.

Most answers recommend against using both at the same time, and maybe use a reliable UDP library, because of the TCP induces UDP packet loss argument stated in this paper for example.

But, if I don't use them both at the same time, e.g. using TCP when the players are still in the lobby/room and then sending data like who are in the room, players data, who just joined the room, etc. where everything must be reliable but also pretty infrequent and then as soon as the game started it switches to UDP to send data like movement, position, etc. where some packet drops is okay, is it okay to do this?

What about if the server is currently handling multiple games at once, like one game is currently playing (using UDP) and another one is still in the room (using TCP)? Will there be a massive packet loss for UDP?

Also about the simultaneous TCP and UDP packet loss, is it only happening if we use them in the same port or does it still happen regardless?

Answer 1

You need to always remember that UDP and TCP are both just protocols on top of the IP layer, which is packet-based like UDP. When you send data via UDP or TCP both will result in a number of IP packets being sent out (and also received back as acknowledgement in the case of TCP).

Look at layer 3 and 4 in this model: Wikipedia - OSI Model

This means that if you use your TCP stream recklessly it'll affect the UDP packet-loss because both use the same shared network resources in the form of IP packets.

---

Now here's the difference:

Sending a single UDP packet usually (depending on the payload size) results in a single IP packet being sent, it's very deterministic. This means you can control how much data you send per second accurately down to the byte level. Games need this since you want every client to get his dose of time-critical data just at the right time. Also server and client need to control how much they saturate their connection, otherwise packet loss happens on the IP level which translates into a slow-down (and build-up of data!) for TCP streams and loss of UDP packets.

With TCP you do not have direct control over how pushing out some bytes results in IP packets being emitted. This can lead to you accidentally saturating your connection when sending a large chunk of data or when many small pieces of data build up in the outgoing buffer.

TCP is greedy: it'll try to send the data you put in as fast as possible but will throttle back once it loses IP packets, resend the data, speed up again, rinse and repeat. You can surely see how this might strain your network for longer than a single UDP packet would.

---

BUT, this isn't something that just happens at random! You are responsible for how well UDP and TCP go together. Control how much data you push into your TCP streams at any given time, just like with the UDP side, as DMGregory already said in his comment. Do not let large amounts of data build up in the outgoing TCP buffer, you cannot control how and when it get's pushed out, it might eat your bandwidth at the wrong time as a result of trying to "catch-up".

You should be fine as long as you leave some headroom for the overhead TCP creates and control the overall data rate, meaning the combined bandwidth that TCP and UDP use.