<div dir="ltr">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.<div>
<br></div><div>So, yeah, I am not a fan of pull requests because they assume I will just take everything as is...</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 13, 2014 at 10:58 AM, Martin Man <span dir="ltr"><<a href="mailto:mman@martinman.net" target="_blank">mman@martinman.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
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…<br>
<br>
thanks,<br>
Martin<br>
<div class="HOEnZb"><div class="h5"><br>
On 13. 5. 2014, at 6:04, Mike <<a href="mailto:mrivers@gte.net">mrivers@gte.net</a>> wrote:<br>
<br>
> Hello Mike,<br>
><br>
> So after several tests now, I have concluded that the problem<br>
> mentioned below was indeed the cause of multiple client disconnects.<br>
> Since I changed how roundTripTimeout was recomputed, not a single client<br>
> has been disconnected during a multiplayer session.<br>
><br>
> I humbly suggest that roundTripTimeout be reexamined.<br>
><br>
> Saturday, May 3, 2014, 11:03:05 AM, you wrote:<br>
><br>
> M> As is, the roundTripTimeout for outgoing commands are doubled .<br>
> M> The problem I see with this is that as time passes, you're less likely<br>
> M> to have success simply due to fewer and fewer resends. Even if this<br>
> M> command is finally successfully sent, it may be considerably delayed and<br>
> M> if the command is ordered then every command behind it will be delayed<br>
> M> as well.  Depending on the peer's roundTripTime, this could take<br>
> M> very few resends to cause the connection to drop with the default peer<br>
> M> timeoutMinimum.<br>
><br>
> M> It seems like it would be better to simply resend with a 'normal' timeout<br>
> M> to increase the chance of success.  Particularly with ordered data, as<br>
> M> it is the most important command and therefore should get higher priority<br>
> M> resend and not lower.<br>
><br>
><br>
><br>
><br>
> --<br>
> Best regards,<br>
> Mike                            mailto:<a href="mailto:mrivers@gte.net">mrivers@gte.net</a><br>
><br>
> _______________________________________________<br>
> ENet-discuss mailing list<br>
> <a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
> <a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br>
<br>
_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
</div></div></blockquote></div><br></div>