The problem will be latency, maybe there are some situations when you need to make sure you get all the packets in order but others where you don't.
For example , if you send an in-game message then this needs to be in the correct order.
On the other hand if you have a spaceship turning quickly then as it's angle and velocity changes old information becomes useless so you will just introduce lag if you hang around waiting for old packets before doing anything with the new ones.
That's when you turn to using multiple data streams/connections/endpoints. Funnelling multiple data streams with different needs over a single mechanism (TCP, or UDP, or smoke signals) only yields misery, sadness, and death.
I haven't read the whole thing, but the TL;DR appears to be:
If the connection is good then TCP will keep increasing it's Window size until packet loss occurs. This will cause the sender to keep sending more packets. The result of this is that the TCP connection will start to consume most of the available bandwidth effectively drowning out more of the UDP packets (e.g if a buffer in a router starts to become full). TCP is designed to play nice with other TCP connections.
This is probably precisely what you don't want in a game where the UDP packets contain the most important information.
For example , if you send an in-game message then this needs to be in the correct order. On the other hand if you have a spaceship turning quickly then as it's angle and velocity changes old information becomes useless so you will just introduce lag if you hang around waiting for old packets before doing anything with the new ones.
http://gafferongames.com/networking-for-game-programmers/udp...