[ENet-discuss] possible enet bug #2

eye at dihalt.com eye at dihalt.com
Tue Jul 29 02:36:49 PDT 2008


Hello, it's me again.

It seems that if enet encounters two or more
ENET_PROTOCOL_COMMAND_DISCONNECT packets it will NOT send
back acknowledgement to a peer and will NOT generate
ENET_EVENT_TYPE_DISCONNECT event. This may happen due to a
network lang and was sucesfully recreated in my test
environment.

possible cause:

network data is received inside
enet_protocol_receive_incoming_commands() until either
enet_protocol_handle_incoming_commands() marks a packet as
processed or no more network data available.
ENET_PROTOCOL_COMMAND_DISCONNECT is processed inside
enet_protocol_handle_disconnect() function that is state
based. If we have 2 DISCONNECT commands, first call to
enet_protocol_handle_disconnect() will set peer state to
ENET_PEER_STATE_ACKNOWLEDGING_DISCONNECT. But packet will
not be marked as
processed and enet_protocol_receive_incoming_commands()
will continue to process network data! And than second
DISCONNECT command is encountered, 
enet_protocol_handle_disconnect() will call
enet_peer_reset() - no acknowledgement will be sent and no
disconnect event will be generated.

possible fix:

additional state check inside
enet_protocol_handle_disconnect(), like this:

else if( ENET_PEER_STATE_ACKNOWLEDGING_DISCONNECT ==
peer->state )
{
  return true; // second disconnect while previous not
processed
}

What can you say? Is it worth to be fixed or i'm doing
something wrong again? Bug was sucesfully recreated on my
test computers while sending huge amouns of data with
different packet sizes and netwok bandwidths. Happens ~
once a hour, it's not very common for two or more
disconnect packets to be on server side due to a lag :).


More information about the ENet-discuss mailing list