[ENet-discuss] Eating foot... (was: Reliable Sequence Numbers overflowing)

[Lee Salzman]

After even more digging as to why the chance of disconnect still 
remained higher during the sequence number wrap-around transition, I 
found that, yes indeed, there is a case where a mal-ordering of packets
can occur that manifests as the disconnect.

For this to happen with ENet 1.1, you need to have sent 64k reliable 
packets, or some multiple of 64k. If the very first packet in the new 
wrapped-around sequence number space (sequence number 0) either gets 
lost in transit, or reordered amongst other packets in transit, and 
there are packets from the old sequence number space and packets from 
the new sequence number space in the queue, then the next packet coming
in that is also in the new sequence space gets placed accidentally on
the front of the queue, due to a bug in how the sequence numbers between
old and new space were getting compared.

Luckily, this just causes packet delivery to stall entirely since ENet 
just sees a huge gap between the last delivered sequence number and the 
sequence number at the head of the queue, and so decides to stall until 
the intermediate packets get put in place, which they never will...

So I pretty much rewrote how the wrap-around is handled so that there is 
never any transition period for reliable packets, and no more wrapping 
at all for unreliable packets.

While the memory layout of the protocol commands is the same, 
unfortunately how the sequence numbers are handled is slightly 
incompatible with 1.1 now. Next release may have to be 1.2 rather 1.1.1...

Anyway, people who were getting bit by that ENet 1.1 bug may want to try 
out CVS and see if this eliminates it.

Lee