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