Not sure I follow, ENet is a layer ontop of UDP/IP, not TCP/IP.
ENet sends periodic ping packets and if no answer is returned in a given
time, it timeouts the other end.
The behaviour Soren mentions must be something else, a bug perhaps.
On 2012-11-12 16:23, Jay Sprenkle wrote:
I've also seen this behavior while using c# .net code.
Detecting disconnects is problematic while using tcp/ip because of the
design.
Here's what I came up with:
Send something to the client and if it does not answer within a
reasonable time then assume it's down or disconnected.
When you try to connect immediately after another connection failed in
an indeterminate state it seems to occasionally drop you immediately.
If this happens retry the connection from the client. This seems to
recover from the indeterminate state.
On Sun, Nov 11, 2012 at 12:59 PM, Soren Dreijer <[email protected]
<mailto:[email protected]>> wrote:
Hey guys,
I'm trying to track down an issue in one of my ENet server
daemons. I'm not sure if this is an issue in my code or in ENet's,
but I wanted to put some feelers out to see if any of you have
experienced something similar.
Basically, what's happening is that a client fails to connect to
the server from time to time. From the client's perspective, the
connection is established successfully and it gets back an
ENET_EVENT_TYPE_CONNECT event from ENet. From the server's
perspective, however, an ENET_EVENT_TYPE_CONNECT event is never
received, but instead ENET_EVENT_TYPE_DISCONNECT is fired for the
new connection.
After taking a look at the server log, it appears the following is
happening on the server:
1.The server calls enet_peer_disconnect () with an ENetPeer object
to close the connection to a client.
2.ENet never fires an ENET_EVENT_TYPE_DISCONNECT event for this.
3.When a new (and different) client connects, ENet reuses the
other client's ENetPeer object (the object has the same memory
address), but fires ENET_EVENT_TYPE_DISCONNECT rather than
ENET_EVENT_TYPE_CONNECT.
It'd seem that the ENetPeer object is somehow in a weird state
internally in ENet.
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
