[ENet-discuss] Timeout after force disconnected
lsalzman at telerama.com
Mon Mar 29 12:41:02 PST 2004
ENet uses a progressive timeout scheme. Initially, it gives all packets
a window of (RTT + variance) to reply with an acknowledgement.
Should no acknowledgement be delivered during this period, it will
double this time window and resend the packet. If the window exceeds
ENET_PEER_TIMEOUT_LIMIT*RTT it will finally disconnect.
Thus, the ultimate time to notice a forced disconnection is:
the sum, for N = 0 and up, of N*(RTT + variance), such that N*(RTT +
variance) < ENET_PEER_TIMEOUT_LIMIT*RTT
So you can change this behavior in two ways:
1) modify ENET_PEER_TIMEOUT_LIMIT to be much lower than it is, which may
or not cause problems if the RTT of a connection is really low
2) in enet_protocol_send_reliable_outgoing_commands, modify the timeout
limit to just be a constant value, instead of multiplied by the RTT
Now, the exact disconnect timeout behavior I have felt has always been a
little inane, and I'd like to change it to some other behavior just as a
matter of course but I would like some concensus on one of two options I
see most profitable:
Firstly, the cumulative amount of time spent waiting for an
acknowledgement would be maintained, rather than just the current
acknowledgement window. Then...
1) compare this cumulative time to a fixed constant, regardless of RTT
2) compare this cumulative time to ENET_PEER_TIMEOUT_LIMIT*RTT
Any opinions on which might behave better?
On Mon, Mar 29, 2004 at 10:04:08PM +0200, Marcin Zaj?czkowski wrote:
> I have another problem, little releated with previous one.
> After client had force disconnected (e.g. by CTRL-C) server didn't
> notice it for about 75 seconds. It blocks slots what is critical with
> fast clients rotation.
> I tried to send control packets to client (1 per 5 seconds) to faster
> get timeout, but I didn't help.
> Is there any way to reach info about it faster?
More information about the ENet-discuss