<div dir="ltr">Thanks for sharing this!<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 2:40 PM, Krasimir Marinov <span dir="ltr"><<a href="mailto:krasi@jklsemi.com" target="_blank">krasi@jklsemi.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Just to keep the topic up to date (and close it) I’d like to inform you that Lee pushed a fix in master branch<div>
and from my tests so far it seems to work well (and the issue is gone)</div><div><br></div><div>Thanks,</div><div>Krasi</div><div><div class="h5"><div><br><div><div>On Nov 27, 2013, at 4:28 PM, Krasimir Marinov <<a href="mailto:krasi@jklsemi.com" target="_blank">krasi@jklsemi.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Just a small addition...<div><br></div><div>The erroneous case 2. is missing the first line:</div><div>host.c:enet_host_connect:250: peer 0x7f4e604d1a10: connecting to port 48418<br>
</div><div><br></div><div>
The last lines, starting with ">>>", of both cases are "my" connect callback, being called with the argument supplied to ENetPeer instance created after enet_host_connect() call.</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 4:15 PM, Krasimir Marinov <span dir="ltr"><<a href="mailto:krasi@jklsemi.com" target="_blank">krasi@jklsemi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I've been load testing an application, mainly based on ENet, and noticed erroneous behaviour for some of the connection being initiated.<div><br></div><div>The test is performed on localhost and perform ~60K connections sending ~ 120K messages.</div>
<div><br></div><div>The error is that initiating connection to let's say port X I got confirmation (ENet connected callback) for port Y.</div><div>Here are log traces that visualise the sequence of events under which the behaviour is observed:</div>
<div><br></div><div>1. Correct connect:</div><div><div>host.c:enet_host_connect:250: peer 0x7f4e604d1a10: connecting to port 40041</div><div>protocol.c:enet_protocol_handle_incoming_commands:1078: peer 0x7f4e604d1a10: port 40041</div>
<div>protocol.c:enet_protocol_handle_incoming_commands:1127: peer 0x7f4e604d1a10: command ENET_PROTOCOL_COMMAND_VERIFY_CONNECT</div><div>>>>2f00000000000000000000000000000000000000000000000000000000000000<00000000>:(conn 0x7f4dc8030190, peer 0x7f4e604d1a10): connected to port 40041</div>
</div><div><br></div><div>2. Incorrect connect:</div><div><div>protocol.c:enet_protocol_handle_incoming_commands:1078: peer 0x7f4e604d1a10: port 48418</div><div>protocol.c:enet_protocol_handle_incoming_commands:1133: peer 0x7f4e604d1a10: command ENET_PROTOCOL_COMMAND_DISCONNECT</div>
<div>peer.c:enet_peer_reset:372: peer 0x7f4e604d1a10</div><div>protocol.c:enet_protocol_handle_incoming_commands:1078: peer 0x7f4e604d1a10: port 56265</div><div>protocol.c:enet_protocol_handle_incoming_commands:1112: peer 0x7f4e604d1a10: command ENET_PROTOCOL_COMMAND_ACKNOWLEDGE</div>
<div>protocol.c:enet_protocol_handle_incoming_commands:1145: peer 0x7f4e604d1a10: command ENET_PROTOCOL_COMMAND_SEND_RELIABLE</div><div>>>>2f00000000000000000000000000000000000000000000000000000000000000<00000000>:(conn 0x7f4dc800ac00, peer 0x7f4e604d1a10): connected to port 56265</div>
</div><div><br></div><div>What happens, in 2., is that a peer that I've just created to connect receives an "unexpected" disconnect message and resets the peer, peer.c:enet_peer_reset:372: peer 0x7f4e604d1a10, which doesn't clear the user supplied data (ENetPeer->data) and when the peer is reused I get incorrect data attached to it.</div>
<div><br></div><div>I've applied the following patch to protocol.c, which seems to work. Unfortunately I'm unable to predict all positive/negative consequences of it, so I'm asking for another opinion/ideas :). Here is the patch (simply skip processing disconnect messages when in state CONNECTING):</div>
<div><br></div><div><div>protocol.c</div><div>817c817,818</div><div>< if (peer -> state == ENET_PEER_STATE_DISCONNECTED || peer -> state == ENET_PEER_STATE_ZOMBIE || peer -> state == ENET_PEER_STATE_ACKNOWLEDGING_DISCONNECT)</div>
<div>---</div><div>> if (peer -> state == ENET_PEER_STATE_DISCONNECTED || peer -> state == ENET_PEER_STATE_ZOMBIE || peer -> state == ENET_PEER_STATE_ACKNOWLEDGING_DISCONNECT</div><div>> || peer->state == ENET_PEER_STATE_CONNECTING)</div>
</div><div> </div><div><br></div><div>Regards,</div><div>Krasi</div></div>
</blockquote></div><br></div>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><i style="font-size:12px;font-family:Verdana,Helvetica,sans-serif"><a href="http://xkcd.com/1156/" target="_blank">http://xkcd.com/1156/</a></i><br><div><div><font face="Verdana, Helvetica, sans-serif"><span style="font-size:12px"><i><br>
</i></span></font><div><br></div></div></div>
</div>