[ENet-discuss] Channel Incoming Unreliable Commands List Management Question

[Lee Salzman]

I put out a 1.3.5 hot-fix release you can try downloading and testing. It should resolve the issue...

On 07/31/2012 05:28 PM, Alexander Dolgansky wrote:
> Hi Lee.
>
> I am using unreliable fragment option that you've added to ENet
> version 1.3.2 (although I am using version 1.3.3 at the moment) and
> I've noticed that if the if statement listed below is true, then
> channel->incomingUnreliableCommands list starts to grow without bound
> if connections with the remote peer is maintained:
>
> if (incomingCommand ->  unreliableSequenceNumber<  startSequenceNumber)
> (part of the enet_protocol_handle_send_unreliable_fragment function
> defined in protocol.c file).
>
> > From what I can see, it appears that some fragments get dropped along
> the way leading to startSequenceNumber to jump ahead of the expected
> value. That is to say, the previous message is only partially
> delivered before the fragments of the new one begin to arrive. What is
> worst is that at some point it is possible to get into situation when
> no fragmented messages can be re-assembled because the incomingCommand
> ->  unreliableSequenceNumber is always less than startSequenceNumber.
>
> This happens only when I try to send messages through a wireless
> interface. Sending messages through wired interface does not lead to
> above problem.
>
> In attempt to fix this problem, I've decided to simply clear
> channel->incomingUnreliableCommands list whenever above if statement
> is true. It seems to work O.K., but I am not sure if that is
> appropriate in the long run.
>
> Can you let me know if that's O.K. thing to do or is there a better
> way to fix the problem?
>
> Also, even though this may simply be a property of the wireless
> communication, I am a bit surprised to see above if statement trigger
> only after about 15 iterations on every message I send out (which
> doesn't change in size in any significant way). Again, this maybe due
> to consistent packet loss, however, I would like to know if there is
> something I can do to improve this situation.
>
> Thanks.
>
> Alexander.
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>