I want to make a multiplayer game that runs on the Internet, not just low-latency, high throughput environments like LAN.
There are some networking aspects of my game where UDP clearly is better suited for, like transmitting information about the positions and velocities of various players. This data must be received as fast as possible, and resending dropped packets will not help because that data is irrelevant by the time it reaches the client. It is entirely OK for some packets to be dropped.
However, there are some other aspects of my game which strictly require in-order, guaranteed delivery. Automatic fragmentation (breaking apart and putting back together for large pieces of data) of packets would also be very useful. It seems like TCP does all of this. Data is not at all useful unless it is strictly in-order and there are no missing packets. Latency will inevitably suffer for this type of data in some cases, but that is unavoidable.
So, instead of implementing TCP-like features on top of UDP, (with data buffers, labeling packets with numbers to determine their order, packet acknowledgement systems), which, would be a ton of work to ensure it works correctly and efficiently, I'd like to just use TCP and UDP at the same time.
However, I have heard that TCP and UDP can fight each other for bandwidth if you use them together at the same time, and using TCP will increase the rate of UDP dropped packets. Is this really true? Are there any other issues that I will have to deal with when mixing these two protocols?
If you are having difficulties, I suggest putting an additional layer of abstraction between you and the guts of your networking code. Try a multiplayer networking library like "RakNet".
You could check for http://www.zeromq.org/, a good opensource intelligent transport layer library.
Normally - using TCP would not increase the rate of drop of UDP packets. It'd rather be other way round - a high volume UDP traffic would throttle TCP traffic as a really rogue UDP implementation can throttle entire network bandwidth - where as TCP would try to maximize throughput for perceived bandwidth. So using them together should not really hurt you, so long as you don't end up hitting the available b/w at a station on a sustained basis. Going beyond that might incur some buffering delays - which would hurt both UDP or TCP applications if they are latency sensitive. Hope that helps.
Try iperf and you will see that if one TCP connection for download has to share a 100 Mb/s line with an application forcing 100 Mb/s UDP download traffic, then you will measure roughly a TCP throughput of 50 Mb/s and receive about half the number of sent UDP packets (i.e., a UDP drop rate of about 50%).
