[ENet-discuss] Outgoing timeout in enet_protocol_check_timeouts()

Martin Man mman at martinman.net
Tue May 13 00:58:06 PDT 2014


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




More information about the ENet-discuss mailing list