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. Thanks. Alexander. _______________________________________________ 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
