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

[Alexander Dolgansky]

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.