[ENet-discuss] Outgoing timeout in enet_protocol_check_timeouts()

[Mike]

Hello Martin,

        Certainly.  The change was simply a copy and paste from
enet_protocol_send_reliable_outgoing_commands() where roundTripTimeout is
initially assigned.

The lines I changed in enet_protocol_check_timeouts() are...

removed:
  outgoingCommand -> roundTripTimeout *= 2;

replaced with:
  outgoingCommand -> roundTripTimeout = peer -> roundTripTime + 4 * peer -> roundTripTimeVariance;
  outgoingCommand -> roundTripTimeoutLimit = peer -> timeoutLimit * outgoingCommand -> roundTripTimeout;

Tuesday, May 13, 2014, 3:58:06 AM, you wrote:

MM> Hi,

MM> 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


MM> thanks,
MM> Martin

MM> 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