Prevent TCP connections from causing UDP packet loss

Question

Consider the prototypical multiplayer game server.

Clients connecting to the server are allowed to download maps and scripts. It is straightforward to create a TCP conn

Answer 1

"# If you're worried about losing UDP packets, you should consider not using UDP."

Right on. UDP means no guarentee of packet delivery, especially over the internet. Check the TCP speed which is quite acceptable in modern day internet connections for most users playing games.

Answer 2

It sounds a lot like you're solving a problem the wrong way:

1. If you're worried about losing UDP packets, you should consider not using UDP.
2. If you're worried about sharing bandwidth between two functions, you should consider having separate pipes (bandwidth) for them.
3. Traffic shaping (which is what this sounds like) is typically addressed in the OS. You should look in that direction before making strange changes to your application.
4. If you haven't already gotten the application working and experienced this problem, you are probably prematurely optimizing.

Answer 3

To avoid saturating the bandwidth, you need to apply some sort of rate limiting. TCP actually already does this, but it might not be effective in some cases. For example, it has no idea weather you consider the TCP or UDP traffic to be the more important.

To implement any form of rate limiting involving UDP, you will first need to calculate UDP loss rate. UDP packets will need to have sequence numbers, and then the client has to count how many unique packets it actually got, and send this information back to the server. This gives you the packet loss rate. The server should monitor this, and if packet loss jumps after a file transfer is started, start lowering the transfer rate until the packet loss becomes acceptable. (You will probably need to do this for UDP anyway, since UDP has no congestion control.)

Note that while I mention "server" above, it could really be done either direction, or both. Depending on who needs to send what. Imagine a game with player created maps that transfer these maps with peer-to-peer connections.

While lowering the transfer rate can be as simple as calling your send function less frequently, attempting to control TCP this way will no doubt conflict with the existing rate control TCP has. As suggested in another answer, you might consider looking into more comprehensive ways to control TCP.

In this particular case, I doubt it would be an issue, unless you really need to send lots of UDP information while the clients are transferring files. I wold expect most games to just show a loading screen or a lobby while this is happening. Neither should require much UDP traffic unless your game has it's own VOIP.

Here is an excellent article series that explains some of the possible uses of both TCP and UDP, specifically in the context of network games. TCP vs. UDP

In a later article from the series, he even explains a way to make UDP 'almost' as reliable as TCP (with code examples).

And as always... and measure your results. You have no way of knowing if your code is making the connections faster or slower unless you measure.