Quote:Original post by dmail
This is the method which many UDP based games that want reliable delivery use, the author also has other articles which may interest you.

I did my own reliable protocol much like that years ago (bitmapped ack windows /flow control/etc..) and it worked fairly well (for what I was using it for). I did somewhat different by usually doing resends when the ACK window indicated a packet was missing (for 'reliable' mode data versus a seperate stream of reliable-unneeded data).
I did have large packets being parts of long data blocks which had to be sent intact. And also had frequent bi-directional traffic to constantly have a stream of ack data traveling in both directions (many games have a majority of the traffic headed out to a client).

The author says to have the application rebuild more data instead of resending the lost packets. That needs more explanation (and examples as that gets complicated). It might be as simple as having a flag on the packets to prevent resend because the content was data which is constantly updated (versus single event type data that isnt sent again). You may have to segregate reliable vs reliable-unneeded data to different packets.

The application might (depending on the process flows) have to do alot of work to reconstitute the 'patched' (versus 'resent') data -- so automatically using that as a strategy might not fit all usages.

Another scheme Ive heard of (when data isnt large) is to piggyback the last data load onto the subsequent packet which can cut down a majority of resend scenarios (single packet loss) -- as long as the bandwidth isnt impacted.