[ENet-discuss] ENet-discuss Digest, Vol 109, Issue 9

Tue Jul 31 13:14:01 PDT 2012

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,  <enet-discuss-request at cubik.org> wrote:
> Send ENet-discuss mailing list submissions to
>         enet-discuss at cubik.org
>
> 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
>         enet-discuss-request at cubik.org
>
> You can reach the person managing the list at
>         enet-discuss-owner at cubik.org
>
> 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 <alexd221 at gmail.com>
> To: enet-discuss at cubik.org
> Subject: [ENet-discuss] Channel Incoming Unreliable Commands List
>         Management      Question
> Message-ID:
>         <CABK46nfUDXJY5kZ3T9H2DQ5gVd+VOCa=8+-v4ieqwCV9-fNUZQ at 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 <lsalzman at gmail.com>
> To: Discussion of the ENet library <enet-discuss at cubik.org>
> Subject: Re: [ENet-discuss] Channel Incoming Unreliable Commands List
>         Management Question
> Message-ID: <5017991C.5080302 at gmail.com>
> 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
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>
>
>
> ------------------------------
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
> End of ENet-discuss Digest, Vol 109, Issue 9
> ********************************************