G'day,
During development we found an issue with the way ENet handles the
disconnect command. We generally service our host 30 times per second (in
step with our framerate), however, during a level load there's an
unavoidable second or two where the game finalises some data - we found
that, if the host disconnected the client during this time, the client would
never be notified of the disconnect - the peer representing the host on the
client machine would simply become reset.
After some investigation, we found that this was happening:
- Client goes into its 1-2 second deadstate;
- Host issues a ENET_PROTOCOL_COMMAND_DISCONNECT command to the client;
- Host times out the command, having not received an acknowledgement, and
resends it (this can happen easily in a LAN environment where ping is low);
- Client wakes up from its deadstate and starts to call enet_host_service;
- Client receives the initial disconnect command, and
enet_protocol_handle_disconnect transitions to
state ENET_PEER_STATE_ACKNOWLEDGING_DISCONNECT;
- Client immediately receives the second disconnect command, and
enet_protocol_handle_disconnect calls enet_peer_reset -- the client is then
not notified of the disconnection.
Our solution was to not reset the peer if the peer is in
the acknowledging disconnect state -- changing:
if (peer -> state != ENET_PEER_STATE_CONNECTED && peer -> state !=
ENET_PEER_STATE_DISCONNECT_LATER)
to:
if (peer -> state != ENET_PEER_STATE_CONNECTED && peer -> state !=
ENET_PEER_STATE_DISCONNECT_LATER
&& peer -> state != ENET_PEER_STATE_ACKNOWLEDGING_DISCONNECT)
solved our issue.
I thought I would share this, as it was tricky to track down, and there's
also the possibility that I'm Doin' It Wrong and there's another solution
that I have overlooked... J
Regards,
- Blair
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
