[ENet-discuss] Channel Incoming Unreliable Commands List Management Question
lsalzman at gmail.com
Tue Jul 31 01:36:44 PDT 2012
That's a really bad idea, and way more effort as a workaround than it needs to be. Just use the normal reliable fragment mechanism (i.e. don't supply the flag) for now while I investigate if there is a library issue or if there is some hidden user error at fault here.
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.
> ENet-discuss mailing list
> ENet-discuss at cubik.org
More information about the ENet-discuss