I'm making a multiplayer game (lazertag) with real hardware.
After hours of research, I'm choosing the UDP instead of the TCP protocol to exchange data.
Because of how unreliable UDP is and because players want speed, I decided to have everything in the game that transmits data to transmit the same data more than once.
Due to my hardware limitations (AT89S52 microcontroller with HM-TRP radio modem set to 56kbps) and features I want in the game, I feel the maximum number of duplicate packets I should send out (along with the original) is 2 or 3 total.
Also, I have it setup where the receiver sets a flag if it receives an entire packet so it doesn't receive any more duplicate packets.
Currently, I have it where the server deliberately pauses between sending uninterrupted sets of duplicate packets. This pause indicates to the clients that a timeout occurred and that the next data that arrives is not part of the duplicate set.
Based on how I'm separating duplicate data, I find the method a bit slow because I have one global timer available to me. If I set the clock too small then the system basically freezes since there will be no time for other tasks to execute. Yes I'm literally time-slicing. If I set the clock too high, then the player could stall for a long time if he is disconnected from the network.
I thought of designating a special byte in the packet to indicate end of duplicate data but that probably won't work because chances are, that data won't be processed by the recipient (because he didn't receive it).
Is there any other way a player's hardware can efficiently know when duplicate packets are finished being sent instead of depending on a long timeout and letting the time run out?
Also, How many duplicate UDP packets would be necessary on a slowish connection (think high-speed dial-up internet) in order for the destination to receive at least one of the duplicates?