The problem with re-sending data multiple times is two-fold:

1) You're cutting your effective throughput in twice (or more), instead of only cutting it by, say, 10%, in reserve for a bad connection.

2) Packet loss seldom happens to a single packet. The two most common problems with packets are:
a) Packet re-ordering; this happens on wireless and modem links with some frequency.
b) Packet storms; some router gets congested, and starts dropping packets for a second or two. It's likely to drop more than one of your packets.

If you drop two packets in a row, then your scheme will not guarantee that the data makes it through, but you're still paying a big price for it (in effect, halving throughput AND doubling latency, assuming transmission is the biggest chunk of latency).

This is why most commercial implementations use sequence numbers and acks/naks of some sort, possibly coupled with a time-out re-transmit.

I've got various sequence counters, etc. installed as well. The reason my solution has been working so far is probably that my data packets are tiny - think 12-24 bytes. Almost all I'm sending are user input and sync packets. The UDP header overhead on uncompressed connections is bigger than that. Even if I have 2 or 3 messages in one packet, header vs data is roughly 50/50. Exactly how many redundant packets are used, and which ones (it can 'piggy-back' resent messages on top of later packets) depends entirely on the network statistics gathered.

I'm not saying my solution is ideal, and I haven't had a chance to test it extensively yet, as the game isn't properly playable yet, but in preliminary tests it's been working fairly well.

The main problem is that messages *must* arrive or the game will go out of sync, and latency should be kept at a minimum, or the game will temporarily go out of sync for too long. Keeping requesting packets that didn't arrive should be avoided in such a situation.

~phil