[ENet-discuss] Outgoing timeout in enet_protocol_check_timeouts()

[Lee Salzman]

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 <mman at martinman.net> 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 <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
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20140513/61011911/attachment.html>