dropped TCP packets are just waited for at the router to be resent again

Routers, in general, do not wait for re-transmission before they forward, because they work at the IP layer, not the TCP layer.
For "reverse NAT servers" this changes, as they play the role of end-points, but when you talk about "router" in general internet parlance, you typically mean the boxes that sit in the middle of the network.

The re-transmission in TCP is entirely handled by the endpoints -- the machine doing the sending, and the machine doing the receiving on the other end.
And if one packet is dropped or delayed, ALL THE PACKETS AFTER THAT PACKET ARE HELD when they are received, waiting for the dropped/delayed packet to be re-sent.
By the time the dropped packet is detected, re-transmitted, and received on the other end, anything that was sent after that is also late, because it's been sitting in the kernel, received by the host, but not delivered to the application, because of the in-order guarantee.

Regarding spraying 100 packets at the same time, that doesn't really help, because the main reason a packet is dropped, is that there is congestion at some node on the network.
Once there is congestion, if the node receives 1 packet from you, or 100 packets from you, they will all be dropped at that time until the congestion recovers.
If you want to try duplication, consuming bandwidth in an attempt at higher robustness, it's much more robust to perhaps include the last 2-3 packets as copies in the next packets you send, so there is some time between each. This will add a bit of overhead, but if you structure your data right, it will RLE compress really well, and thus won't actually consume 200-300% of the bandwidth.
If the network drops three successive packets with a packet-send delay between each, the congestion is likely so bad that you're going to have a bad playing experience no matter what.

A bit more on that...

You seem to already know some of this, but the nature of the questions means it bears repeating:

TCP is stream based. The protocol makes sure that you get what was sent, in the exact order it was sent. This is wonderful if you prefer a guarantee that everything arrive in the order it was sent. If something was dropped on the network the underlying protocol will tell you it isn't ready yet, and it will do its job behind the scenes to request the missing data and ensure that your stream is given to you in the order it was sent. This isn't necessarily wrong or bad, and if you need a stream based system it can be exactly what you need.

UDP is packet based. The protocol gives you items as fast as they are received, and does not take steps to deal with network hiccups. This is wonderful if you prefer data is available as soon as it arrives. However, if something was dropped on the network the protocol won't automatically request it for you; if a network hiccup gives you a packet multiple times, twice or three times or twenty times, you'll get copy after copy as they arrive. This isn't necessarily wrong or bad, and if you want data as soon as it arrives it can be exactly what you need.

Raknet, like many game networking libraries use UDP for their communication and then implement an optional stream-based protocol on top of it. This way you can specify how you want the data. If you want the data as fast as it arrives then you can flag it to use that version of their protocol, but in exchange you need your code to deal with missing packets, duplicate packets, and the rest. If you want your data stream based you can flag it to use that variation of their protocol, but in exchange you need your code to deal with the fact that sometimes the stream will stop after network hiccups and it may cause a delay.

Whichever version you end up taking you will need to design in ways to deal with latency and with network hiccups. There are many tips and tricks out there for dealing with them. Some of them can be masked with simple tricks: an audio cue ("Yes, sir!") or an animation (slight gun lift and trigger pull) can buy you 100-200 milliseconds. For bullets, introducing flight time on the shot can gain you another few hundred milliseconds. A bullet may travel about 4000 feet per second, so there's another 10 milliseconds of network time. Dead reckoning and predictions with rewinding and injecting events are more difficult to implement, but they can further reduce the perceived network performance. You can implement any or all of those things using either stream-based or packet-based networking protocols.

Guys, thanks A LOT for the thorough answers. ^_^

I'm really starting to get into this stuff. :cool: