Thanks for sharing this!
On Wed, Nov 27, 2013 at 2:40 PM, Krasimir Marinov <[email protected]> wrote: > 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 > and from my tests so far it seems to work well (and the issue is gone) > > Thanks, > Krasi > > On Nov 27, 2013, at 4:28 PM, Krasimir Marinov <[email protected]> wrote: > > Just a small addition... > > The erroneous case 2. is missing the first line: > host.c:enet_host_connect:250: peer 0x7f4e604d1a10: connecting to port 48418 > > 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. > > > On Wed, Nov 27, 2013 at 4:15 PM, Krasimir Marinov <[email protected]>wrote: > >> I've been load testing an application, mainly based on ENet, and noticed >> erroneous behaviour for some of the connection being initiated. >> >> The test is performed on localhost and perform ~60K connections sending ~ >> 120K messages. >> >> The error is that initiating connection to let's say port X I got >> confirmation (ENet connected callback) for port Y. >> Here are log traces that visualise the sequence of events under which the >> behaviour is observed: >> >> 1. Correct connect: >> host.c:enet_host_connect:250: peer 0x7f4e604d1a10: connecting to port >> 40041 >> protocol.c:enet_protocol_handle_incoming_commands:1078: peer >> 0x7f4e604d1a10: port 40041 >> protocol.c:enet_protocol_handle_incoming_commands:1127: peer >> 0x7f4e604d1a10: command ENET_PROTOCOL_COMMAND_VERIFY_CONNECT >> >>>2f00000000000000000000000000000000000000000000000000000000000000<00000000>:(conn >> 0x7f4dc8030190, peer 0x7f4e604d1a10): connected to port 40041 >> >> 2. Incorrect connect: >> protocol.c:enet_protocol_handle_incoming_commands:1078: peer >> 0x7f4e604d1a10: port 48418 >> protocol.c:enet_protocol_handle_incoming_commands:1133: peer >> 0x7f4e604d1a10: command ENET_PROTOCOL_COMMAND_DISCONNECT >> peer.c:enet_peer_reset:372: peer 0x7f4e604d1a10 >> protocol.c:enet_protocol_handle_incoming_commands:1078: peer >> 0x7f4e604d1a10: port 56265 >> protocol.c:enet_protocol_handle_incoming_commands:1112: peer >> 0x7f4e604d1a10: command ENET_PROTOCOL_COMMAND_ACKNOWLEDGE >> protocol.c:enet_protocol_handle_incoming_commands:1145: peer >> 0x7f4e604d1a10: command ENET_PROTOCOL_COMMAND_SEND_RELIABLE >> >>>2f00000000000000000000000000000000000000000000000000000000000000<00000000>:(conn >> 0x7f4dc800ac00, peer 0x7f4e604d1a10): connected to port 56265 >> >> 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. >> >> 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): >> >> protocol.c >> 817c817,818 >> < if (peer -> state == ENET_PEER_STATE_DISCONNECTED || peer -> state >> == ENET_PEER_STATE_ZOMBIE || peer -> state == >> ENET_PEER_STATE_ACKNOWLEDGING_DISCONNECT) >> --- >> > if (peer -> state == ENET_PEER_STATE_DISCONNECTED || peer -> state >> == ENET_PEER_STATE_ZOMBIE || peer -> state == >> ENET_PEER_STATE_ACKNOWLEDGING_DISCONNECT >> > || peer->state == ENET_PEER_STATE_CONNECTING) >> >> >> Regards, >> Krasi >> > > > > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss > > -- *http://xkcd.com/1156/ <http://xkcd.com/1156/>*
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
