If you excuse my garbage meme (I'm just trying to keep my sanity together, just cut me some slack, ok?), this patch adds a bit of robustness to the netcode that (hopefully) allows it to recover in case of a packet that a node didn't register in it's acktosend list.
The way reliable packets works is that it uses a table of packets that have been sent with a unique, incremental number that is used to identify a packet that has been responded to. If the target node sends that same number back at some point, it can be certain that the server has read and processed it, and followup packets can be processed as usual. However, in this process, the node also need to keep track of packets that it has processed, in case it fails to send it's acknowledgement back and the other node ends up resending the packet. This is where the acktosend list comes into play: it lists all packets that it has processed recently, and if a packet already in the list appears there, it knows it has seen it already and can safely ignore it.
Here's where I think it goes wrong: there are two procedures for duplicate packets, one is a sliding window that incrementally goes up to process the last packet, and if an acknowledgement number comes before it, it can be sure it's already been processed. Or, at least, should be, since I can think of one theoretical situation where this is false: out-of-order packets. In that case, the server will still try to respond with an ackreturn for that packet for a quick response, but it actually never adds it to the acktosend table since it has assumed it's already been processed. If this happens before the packet was added to acktosend table, it's possible that it ignores the packet and never send an ack back, locking up the node's ackpak list.
The solution to this is by checking the acktosend list for duplicates first, and if it's not there, proceed to add it in the list even if it's perceived to be a duplicate, to really make sure that the node gets the packet acked. This should hopefully eliminate the chances of a lockup in case a node end up not acking it.
I will try to keep a server up with this patch the follow days while I'm awake to really give this a proper and thorough testing. If you want to join, I made a build of this patch that you can use (make a copy of your 2.2.13 installation first - you might lose data otherwise!): srb2win.zip
