There is only a 16 bit sequence number space for unreliable packets, and sending a reliable packet resets the sequence number space. You can't just comment out that part because then the sequence numbers will never reset.
On Sun, Apr 24, 2016 at 2:24 PM, <[email protected]> wrote: > Hi, > > I have a use case where I'm sending large numbers of unreliable fragmented > packets and easily overflowing the sequence numbers. I noticed that in > enet_peer_send, there's an explicit check on sequence number 0xFFFF: > > if ((packet -> flags & (ENET_PACKET_FLAG_RELIABLE | > ENET_PACKET_FLAG_UNRELIABLE_FRAGMENT)) == > ENET_PACKET_FLAG_UNRELIABLE_FRAGMENT && > channel -> outgoingUnreliableSequenceNumber < 0xFFFF) > //set flags to send packet unreliably > else > //set flags to send packet reliably > > It seems arbitrary to me to send a packet flagged as unreliable as a > reliable packet for a particular value in the sequence number. Commenting > out that last part of the if statement fixes the error in my specific use > case. Is unreliable sequence number 0xFFFF reserved for a specific reason? > Is there anything that might break if this check is removed? > > Thanks for any insight. > > > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss > _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
