[ENet-discuss] Question about ENet and reconnecting

[Doug Warren]

It's unlikely that the client will reuse the same outgoing port on multiple
reconnects in the real world.  Once you add NATs  to the picture things get
much messier than an internal network.  That said, I had to do something
similar but different (Allow the same enet peer ID from any ip/port) to
handle the case of a network connection migrating from cellular to wifi.
 In turn though I had to add application layer security to prevent
spoofing/replays.


On Wed, Jul 31, 2013 at 6:46 AM, Patrick Klos <pklos at lauferwind.com> wrote:

> Hello ENet mailing list,
>
> I am new to ENet and have been tasked with learning how it works in our
> environment.
>
> After running some packet traces, I noticed that when our "server" uses
> enet_host_broadcast(), it would sometimes send the broadcasted packet to a
> given "client" peer twice (with different sequence numbers).  I tracked it
> down to the fact that the client timed out the server, the client uses
> enet_peer_reset() to discard the apparently broken connection, and then
> used enet_host_connect() to reconnect to the server.  The problem appears
> when the server accepts the new connection for the client while still
> maintaining the old connection for the client.  This happens because the
> new connection has a different "connectID" value, so
> enet_protocol_handle_connect() [protocol.c line 297] doesn't associate the
> new connection with old connection using the same IP address and port.
>
> Before I jump to conclusions, let me ask is there any scenario where ENet
> would want to maintain more than connection between a pair of IP addresses
> and ports?  Could there be a legitimate use for setting up more than one
> ENet connection between a single client and server?
>
> And if the answer to the previous question is NO, would there be any harm
> in adding code to enet_protocol_handle_connect() such that if it runs into
> a peer that uses the same IP address and port (but obviously a different
> connectID) that the new connection is coming in on,
> enet_protocol_handle_connect() would immediately reset the old peer and
> then proceed let the new peer be created?
>
> Perhaps changing this: (starting at line 290)
>
>     for (currentPeer = host -> peers;
>          currentPeer < & host -> peers [host -> peerCount];
>          ++ currentPeer)
>     {
>         if (currentPeer -> state != ENET_PEER_STATE_DISCONNECTED &&
>             currentPeer -> address.host == host -> receivedAddress.host &&
>             currentPeer -> address.port == host -> receivedAddress.port &&
>             currentPeer -> connectID == command -> connect.connectID)
>           return NULL;
>     }
>
> To this?
>
>     for (currentPeer = host -> peers;
>          currentPeer < & host -> peers [host -> peerCount];
>          ++ currentPeer)
>     {
>         if (currentPeer -> state != ENET_PEER_STATE_DISCONNECTED &&
>             currentPeer -> address.host == host -> receivedAddress.host &&
>             currentPeer -> address.port == host -> receivedAddress.port)
>         {
>             // if using the same connectID, behave like before
>             if (currentPeer -> connectID == command -> connect.connectID)
>                 return NULL;
>
>             // new connection from existing peer - reset the existing
> connection now
>             enet_peer_reset(currentPeer);
>
>             // we can stop looking since we won't find another match
>             break;
>         }
>     }
>
> Thanks,
>
> Patrick
>
> ______________________________**_________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/**mailman/listinfo/enet-discuss<http://lists.cubik.org/mailman/listinfo/enet-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20130731/7895f83a/attachment.html>