[ENet-discuss] Inconsistent connection status between hosts in bad network conditions

Tue Jun 23 05:38:12 PDT 2015

Dear Kristin,

Also as a follow-up. Why I assumed it is a military application and/or
emergency (bombing/fire/high security installation/medical life support
equipment) is that in normal circumstances, a packet drop of above 2%
usually means you have to adjust the bandwidth and/or send your packets
more "harmoniously" as you are overloading the client and thus creating a
bottleneck somewhere down the line. If you insist on having a connection at
95% packet loss you are looking at "un-normal" operational conditions. Was
I close?

The way I do it using ENet is that I try to re-connect on a disconnect
event and so far I had not had a problem even at 95% packet loss (when I
flood the client with data for example).

Best regards,

Pablo

On Tue, Jun 23, 2015 at 1:12 PM, Pablo de Heras Ciechomski <
pablo.deheras at gmail.com> wrote:

> Hi Kristin,
>
> From what I know of people working for the military in networking matters
> they use openDDS. Your scenario seems worst possible conditions so they
> might have support for that in openDDS, no idea, but in my mind ENET is not
> built for "ultimate" reliability of connection rather "ultimate" speed of
> delivery and assumes a not too bad connection.
>
> I do not work for or endorse openDDS, nor do I use it as I prefer the
> lightweight ENet.
>
> Best regards,
>
> Pablo
>
> PS - Maybe you can cut a deal with Lee to extend it for this circumstance
> and we all benefit? Nudge, nudge.
>
> On Thu, Jun 18, 2015 at 3:56 PM, <kristin.nielsen at se.atlascopco.com>
> wrote:
>
>> I've been investigating a system with two Enet hosts under bad network
>> conditions, and noticed  a spurious disconnect at the server.
>>
>> I've used Enet v.1.3.13 and for simulating bad network I've used netem
>> with configuration "delay 100ms 100ms 5% loss random 45% corrupt 35%"
>> which means a delay of all packets of 100ms a random loss of 45% for all
>> packets and 35% of all packets are corrupt.
>>
>> At first, the network is good and both client and server connects to each
>> other, Enet reports ENET_EVENT_TYPE_CONNECT.
>>
>> Then I apply the bad network and both the client and the server
>> disconnects, Enet reports ENET_EVENT_TYPE_DISCONNECT on both client and
>> server.
>>
>> When the bad network conditions are restored, at first, everything seems
>> to work fine. Enet reports ENET_EVENT_TYPE_CONNECT  for both client and
>> server.
>> But then, after some second, I will get a spurios ENET_EVENT_TYPE_DISCONNECT
>> on the server side only. The client still thinks everything is up and
>> running.
>> And I'm stuck in a state that I can only get out from by restarting one
>> of the applications(either the server or the client doesn't matter)
>> This happens almost everytime.
>>
>> I have also noted that if I apply really bad network, for example a
>> random loss of 95% of all packets, and the restore. Then, I havn't seen
>> this strange disconnect.
>>
>> Best regards,     *Kristin Nielsen*
>> * Software Developer LHD Applications*
>> * Rocktec Division*
>> ------------------------------
>>  Atlas Copco Rock Drills AB  *Address: * Klerkgatan 21
>> 701 91 Örebro
>> Sweden
>>  *Phone:* +46 019 768 25 85    *E-mail: *
>> kristin.nielsen at se.atlascopco.com
>> *Visit us at: Follow us at:* http://www.atlascopco.com
>> *Facebook * <https://www.facebook.com/atlascopco>/ *Twitter *
>> <https://twitter.com/AtlasCopcoGroup>/ *LinkedIn *
>> <http://www.linkedin.com/company/atlas-copco>/ *YouTube*
>> <http://www.youtube.com/user/atlascopcogroup>  *Committed to sustainable
>> productivity              *
>>  [image: Atlas Copco]
>> <http://www.atlascopco.com.cn/cnus/atlascopcogroup/>
>>
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20150623/f41d77af/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 17203 bytes
Desc: not available
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20150623/f41d77af/attachment-0001.gif>