[ENet-discuss] Outgoing timeout in enet_protocol_check_timeouts()

[Martin Man]

Hi Lee,

I agree with you completely, I’m interested in seeing what the Mike’s fix was and how it relates to existing code and eventually turn it into a PR with full understanding what the changes are :)

The issue I’m seeing is that my peers would drop connection on either side randomly and definitely before reaching the peer timeouts. I have set all timeouts for all peers to 30 seconds, from my understanding that would mean that the connection should never drop should packets get lost earlier than after 30 seconds. Yet what I’m seeing is a CONNECT followed by DISCONNECT after say 5 seconds. Or random DISCONNECT followed by successful CONNECT that then keeps the connection live for hours…

So my question to you would be:

Under what circumstances can ENetHost generate a DISCONNECT event for a peer?

My thinking was that one of the cases is that it does not receive a reliable packet within defined peer timeout window. Are there more cases?

thanks for your time and creating great library :)
Martin

On 13. 5. 2014, at 10:08, Lee Salzman <lsalzman at gmail.com> wrote:

> The exponential backoff is there on purpose, to not just keep overloading a connection that may already be overloaded, and is designed to mimic TCP. I am still not entirely convinced that this is the issue in the main written about here, and even if I were to migrate away from exponential backoff, I would not go straight to no increasing backoffs, but rather split the difference somehow.
> 
> So, yeah, I am not a fan of pull requests because they assume I will just take everything as is...
> 
> 
> On Tue, May 13, 2014 at 10:58 AM, Martin Man <mman at martinman.net> wrote:
> Hi,
> 
> could you please share a git diff or simply outline your changes, I think I’m hitting the same bug and would be happy to compose a pull request for Lee…
> 
> thanks,
> Martin
> 
> On 13. 5. 2014, at 6:04, Mike <mrivers at gte.net> wrote:
> 
> > Hello Mike,
> >
> > So after several tests now, I have concluded that the problem
> > mentioned below was indeed the cause of multiple client disconnects.
> > Since I changed how roundTripTimeout was recomputed, not a single client
> > has been disconnected during a multiplayer session.
> >
> > I humbly suggest that roundTripTimeout be reexamined.
> >
> > Saturday, May 3, 2014, 11:03:05 AM, you wrote:
> >
> > M> As is, the roundTripTimeout for outgoing commands are doubled .
> > M> The problem I see with this is that as time passes, you're less likely
> > M> to have success simply due to fewer and fewer resends. Even if this
> > M> command is finally successfully sent, it may be considerably delayed and
> > M> if the command is ordered then every command behind it will be delayed
> > M> as well.  Depending on the peer's roundTripTime, this could take
> > M> very few resends to cause the connection to drop with the default peer
> > M> timeoutMinimum.
> >
> > M> It seems like it would be better to simply resend with a 'normal' timeout
> > M> to increase the chance of success.  Particularly with ordered data, as
> > M> it is the most important command and therefore should get higher priority
> > M> resend and not lower.
> >
> >
> >
> >
> > --
> > Best regards,
> > Mike                            mailto:mrivers at gte.net
> >
> > _______________________________________________
> > 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
> 
> _______________________________________________
> 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/20140513/4c081b25/attachment-0001.html>