Thanks Lee. I wasn't too sure that the work-around made sense (hence the reason why I asked the question in the first place) so I've only briefly experimented with the it to see how it would affect ENet's behaviour.
In most cases, I can use reliable delivery mechanism, but there are messages (about two fragments long) that I must send best-effort since re-transmission is highly undesirable. I am a bit worried that a blip in communication will cause these messages to never be reassembled on the receiver's side until that receiver has been restarted (which is also undesirable). Anyway, like you suggested, I will use reliable fragment option as much as possible and wait for your update on my issue. Alexander. On Tue, Jul 31, 2012 at 3:00 PM, <[email protected]> wrote: > Send ENet-discuss mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cubik.org/mailman/listinfo/enet-discuss > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ENet-discuss digest..." > > > Today's Topics: > > 1. Channel Incoming Unreliable Commands List Management > Question (Alexander Dolgansky) > 2. Re: Channel Incoming Unreliable Commands List Management > Question (Lee Salzman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 31 Jul 2012 10:28:46 -0400 > From: Alexander Dolgansky <[email protected]> > To: [email protected] > Subject: [ENet-discuss] Channel Incoming Unreliable Commands List > Management Question > Message-ID: > <CABK46nfUDXJY5kZ3T9H2DQ5gVd+VOCa=8+-v4ieqwcv9-fn...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 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. > > > ------------------------------ > > Message: 2 > Date: Tue, 31 Jul 2012 11:36:44 +0300 > From: Lee Salzman <[email protected]> > To: Discussion of the ENet library <[email protected]> > Subject: Re: [ENet-discuss] Channel Incoming Unreliable Commands List > Management Question > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 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 > > > End of ENet-discuss Digest, Vol 109, Issue 9 > ******************************************** _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
