[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