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
