My first question is mostly oriented around this article, it explain that using TCP and UDP at the same time is not a good idea because it increase the loss of UDP paquets because TCP tend to use all the network available for himself.
Read the article more carefully. It is dealing with a saturated network connection. Unless you have people streaming video next to you as you play a game, you probably don't have the saturated connection.
If you have saturated your connection, the article discusses how both systems suffer packet loss but TCP's protocol incorporates retransmission with sliding windows, but UDP's simpler solution does not incorporate retransmission with sliding windows.
There is nothing inherently different between how they use the network, it is only that TCP automatically does some things behind your back. Many games implement exactly the same thing --- or an even better variant --- so they don't suffer that problem.
The typical solution is that data is resent until acknowledged. There have been many posts on it (search the forums) but it looks like this:
Send: {A} // Send block A
Recv: {Ack A} // Acknowledged, they got through that block.
Send: {B} // Send block B
Recv: {Ack B} // Acknowledged, they got through that block.
Send: {C} // Send block C.
Send: {C D} // Send block D plus unacknowledged blocks
Send: {C D E} // Send block E plus unacknowledged blocks
Recv: {Ack D} // Acknowledged, they got through that block
Send: { E F } // Send block F plus unacknowledged blocks
Recv: {Ack F} // Acknowledged, they got through that block.
Send: { G } ...
When data is not acknowledged this requires a little more bandwidth than TCP's sliding windows, but the latency of the sliding window protocol is eliminated. For games the latency is usually a bigger issue than the bandwidth so it tends to work well.
There are ways to resend less data if the packets are deltas rather than full values, but that's more advanced than this conversation.
if you are in a subnetwork and start a TCP connexion, there is no problem with the server responses since the connexion is already open and active, it can just use it. But in the case of UDP, how did that work? There is no alive connexions, ... have i missed something about how UDP work?
Both work the same as far as the Internet Protocol goes, so as far as the routers care they're the same type of traffic, they're all Internet Protocol traffic. Some IP datagrams contain TCP content, others have UDP content, others have DCCP content, others have SCTP content, others may have other content.
The difference to you is that your TCP library keeps track of a bunch of other data for you. It handles the sliding windows and error correction data in a way similar to what was described above, it handles packing up small transmissions and combining them into a single datagram, it handles buffering data so it works as a stream rather than working as packets. The TCP libraries do all this behind your back.
If you are using UDP you can still do exactly the same type of work, you just need to do it all on your own instead of relying on a library to do it.
I was thinking about using uPnP for that, but i'm not sure how to use it.
Because of the questions you are asking, writing your own uPnP code is currently beyond your skills. You'll need to either use a library that does it for you, or continue to learn about networking until you reach the point where you can understand the uPnP protocol before using it.
