[ENet-discuss] Possible bug - more info

Lee Salzman lsalzman1 at cox.net
Tue Jan 8 22:10:27 PST 2008

Okay, I think might know a possibility, but some background first.
The enet connect sequence is as follows:

Client sends CONNECT command to server, and is in state CONNECTING.
Server sends VERIFY_CONNECT  to client and changes state to 
Client receives VERIFY_CONNECT, changes state to CONNECTED, and notifies 
library of connection.
Client sends acknowledgement of VERIFY_CONNECT to server.
Server receives acknowledgement of VERIFY_CONNECT, changes state to 
CONNECTED, and notifies library of connection.
Note that if the client doesn't receive a VERIFY_CONNECT at first, it 
will resend CONNECT
until it does get it. Once it gets VERIFY_CONNECT it stops sending 
functions as an acknowledgement.

Now, here is the only small possible bug I found. In 
enet_protocol_handle_verify_connect() there is an innocent:

    if (peer -> state != ENET_PEER_STATE_CONNECTING)
      return -1;

So the return value of -1 makes the library not acknowledge the 
VERIFY_CONNECT in the event the client is
not in the CONNECTING state. This happens if the client previously 
received a VERIFY_CONNECT, sent out
an acknowledgement, but the server never received the acknowledgement. 
The server will resend VERIFY_CONNECT
because of this, but the client already thinks it is connected (in 
CONNECTED state).  So the client ends up
ignoring the VERIFY_CONNECT and doesn't acknowledge it. The server waits 
for the acknowledgement, but since it never
gets it, it ultimately times out on the server's end and then causes the 

Luckily, the fix is quite simple, and I added it to CVS just now:

    if (peer -> state != ENET_PEER_STATE_CONNECTING)
      return 0;

Returning 0 there instead allows that to still get acknowledged, so no 
more problem.

Hopefully this was the problem you observed.

This (well-hidden) bug aside, CVS ENet has seemed rather stable in the 
recent Sauerbraten release, so I will probably
do an ENet 1.2 release very soon.


Kresimir Cosic wrote:
> Hi again!
> After analyzing some cases of disconnects, I found out a pattern 
> related to the case I described. What happens is that peers are 
> disconnected soon after connecting.
> The problem seems to be that the client sends 
> ENET_PROTOCOL_COMMAND_CONNECT (no. 02) twice, the second time is 
> usually just several packets after initial connect command (and has 
> the same peerId, same challenge, same reliableSequenceNumber...). 
> Well, at least I find it suspicious.
> After that, the connection goes into some half-alive state. The 
> client keeps resending COMMAND_CONNECT, although some data is 
> already coming through, and it seems to me that I also spotted acq 
> for sequence number 0.
> Any ideas what I stumbled upon?
> ...
> Another note about the sniff log that was provided. That log 
> contains a small anomaly at the start, there is one additional 
> unsuccessful connection (I didn't even notice it), but by comparing 
> it to other logs of broken connections (where this doesn't happen) I 
> would say that it could be ignored.

More information about the ENet-discuss mailing list