[ENet-discuss] Unreliable Fragmented Packets and Sequence Overflow

Lee Salzman lsalzman at gmail.com
Sun Apr 24 17:59:39 PDT 2016


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,  <kbm at goldenhammersoftware.com> 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
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>


More information about the ENet-discuss mailing list