[ENet-discuss] Preventing a host from connecting multiple times to another host?

Ruud van Gaal ruud at racer.nl
Thu Jun 17 05:44:56 PDT 2010


...
> Let's say I have hosts A and B. Host A has a zombie 
> connection with B. I suppose that a new connection won't 
> arrive in A unless I initiate it manually from B with 
> enet_host_connect when I see that my current connection with 
> A is lost. In that case, A's zombie connection will just 
> prevent connections from B until it disappears, which will 
> just cause an additional delay until B can reestablish its 
> connection to A. Or can the zombie stay here indefinitely in 
> A, thereby preventing all future connections from B?

In my experience, I can have connection problems when trying to connect to a
host multiple times. The process is:

- the client opens a enet_host with only 1 peer
- the server can handle multiple connections

Every second or so, the client starts a connect attempt to the server.
Quickly, it comes back with errors: 'out of peer connections'.
After some time though, the connect attempts seem to time out and the client
can connect again to the server. I think though that the connect attempts
are retried only every so often (5 seconds?), so trying to establish a
connection, if it fails the first time (the server may not be up yet in my
case) it will take at least 5 seconds to have the first connect attempt to
timeout.

Not sure if this is really related to zombie connections on the server side.
Still, I do have trouble trying to connect to a server when:
- the server may not be up just yet
- it will be up though in a few seconds

Sometimes these timeouts to be able to connect seem to take a really long
time. I tried having the client open more peers, but then the problem only
shifts to a later time (multiple connect attempts are made but ultimately I
fall back in the 'out of peers' error again). And besides, that gets you
back multiple connects on the client side, if more than one succeeds, and I
have to ignore all but the first connection (drop the other ones
immediately).

All a bit awkward in my case.

Ruud



More information about the ENet-discuss mailing list