[ENet-discuss] Impact of high latency on enet (Bitjump)
Ruud van Gaal
ruud at racer.nl
Mon Nov 10 02:34:50 PST 2008
> From: Bitjump <bitjump at gmail.com>
> Subject: [ENet-discuss] Impact of high latency on enet
> To: enet-discuss at cubik.org
> Message-ID:
> <c8e6e2ec0811081430g14a8afa8x882666166607b631 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> For networks that occasionally show spikes in latency such
> that the other end seems unavailable for a short period of
> time, what's the best way to accommodate?
>
> How would one change the following enumerations:
> ENET_PEER_TIMEOUT_LIMIT
> ENET_PEER_TIMEOUT_MINIMUM
> ENET_PEER_TIMEOUT_MAXIMUM
>
> Using enet now I receive a disconnect event under these
> circumstances, where if the same connection were using TCP
> (due to TCPs long timeouts), the connection would eventually
> be available again.
I have an app where sometimes the clients are loading race tracks, which
takes a while. I've modified enet.h to have dynamically settable timeouts:
// dynamic settings (see callbacks.cpp)
extern int ENetPeerTimeOutMinimum;
extern int ENetPeerTimeOutMaximum;
#define ENET_PEER_TIMEOUT_MINIMUM ENetPeerTimeOutMinimum
#define ENET_PEER_TIMEOUT_MAXIMUM ENetPeerTimeOutMaximum
Then in callbacks.cpp:
int ENetPeerTimeOutMinimum=5*60000;
int ENetPeerTimeOutMaximum=5*60000;
This way I can change the timeouts for apps that are controllable (I
supervise them myself, it's not really a customer deal) to allow for longer
delays. Effectively I hardly ever want them to disconnect, only after these
5 minutes or so. Otherwise I'd prefer some kind of automatic reconnect
attempt. I use UDP often as a 'the client is there, and if it's not, just
keep going without delay' mechanism.
I never found the real difference between TIMEOUT_MINIMUM and
TIMEOUT_MAXIMUM; you're say the MINIMUM is a timeout for packets where they
aren't counted for roundtrip times? Or do they also generates DISCONNECT
events? (in which I also have to set these high).
Cheers,
Ruud
More information about the ENet-discuss
mailing list