[ENet-discuss] Reliable Sequence Numbers overflowing

[Lee Salzman]

These values are designed to wrap around so that the space of sequence 
numbers is essentially infinite. Changing them to 32 bit would in fact 
break parts of the code that assume the sequence numbers are 16 bit, and 
would just give you a finite amount of sequence numbers.

The sequence number value just has to be large enough that there can't 
be two packets currently in flight with the same sequence number (taking 
wrapping into account), which a 16 bit value is more than large enough 
for, and 32 bits is just overkill and wasteful for large numbers of packets.

I can look into this a bit, but any detail about how to reproduce the 
issue under the simplest possible test case would be helpful.

Lee

Ben Moreno wrote:
> I've been running into what seems to be a bug when sending a very  
> large number of reliable packets over an ENet connection. Everything  
> will be going fine, then the channel that's being used will just stop  
> getting any packets. No disconnect notice, just no packets. Other  
> channels continue to work.
> 
> While poking around the ENet source to try to find the cause, I  
> discovered that _ENetPeer.outgoingReliableSequence number, and the  
> other 16 bit variables it influences are overflowing. I suspect this  
> may be the cause of the bug I'm seeing.
> 
> My question is, would outgoingReliableSequence overflowing cause  
> reliable packets to stop being delivered? Is there a reason it's 16  
> bit instead of 32? I see a couple of other variables who are  
> influenced by outgoingReliableSequence, who's type would also need to  
> be changed to enet_uint32. Are there any things who's size needs to  
> be changed that I might have missed?
> 
> Thanks,
> Ben