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 <[email protected]> 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 <[email protected]> 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:[email protected] > > > > _______________________________________________ > > 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 >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
