[ENet-discuss] Connecting to self (resolved)
Krasimir Marinov
krasi at jklsemi.com
Tue Nov 12 02:31:52 PST 2013
Thanks Lee!
That sheds some light on this check. I've applied this patch in order to
allow loopback connects:
--- enet-1.3.9/protocol.c 2013-08-18 17:16:04.000000000 +0300
+++ enet-1.3.9.mod/protocol.c 2013-11-12 12:21:18.000000000 +0200
@@ -299,7 +299,10 @@
else
if (currentPeer -> address.host == host -> receivedAddress.host)
{
- if (currentPeer -> address.port == host ->
receivedAddress.port &&
+ /* This check prevents duplicate *connection attempts*
resulting
+ from a connection packet being retransmitted */
+ if (currentPeer -> state != ENET_PEER_STATE_CONNECTING &&
+ currentPeer -> address.port == host ->
receivedAddress.port &&
currentPeer -> connectID == command -> connect.connectID)
return NULL;
Is this the (ENET_PEER_STATE_CONNECTING) check you mentioned?
As for the throttling, based on my shallow view of the current
implementation, I thought it won't be messed, because the
throttling-related bookkeeping is *per peer*, so it won't matter where the
peer comes from (localhost, another host, or the loopback connect). Am I
right?
On Tue, Nov 12, 2013 at 11:27 AM, Lee Salzman <lsalzman at gmail.com> wrote:
> Sorry for the late response, as I was away for the weekend. After looking
> into it, that check ultimately prevents duplicate *connection attempts*
> resulting from a connection packet being retransmitted. There is a quite
> easy work-around for it in theory, by just adding a check for the
> ENET_PEER_STATE_CONNECTING state (which indicates the sender of the connect
> attempt) and skipping it if it is found. What I don't know is if or how
> this will mess up the peer management for things like throttling when there
> are two peers on a single host representing both ends of a single
> connection, if said loopback connections where host and client are the same
> are allowed to proceed.
>
> An enterprising person would have to experiment and verify everything
> works fine, but I myself won't have time to futz with this till the weekend
> at best.
>
>
> On Fri, Nov 8, 2013 at 9:45 PM, Erwin Coumans <erwin.coumans at gmail.com>wrote:
>
>>
>> I suppose Krasimir wants to use a single ENetHosts
>> for server and client for this reason:
>>
>> "If I switch to two separate ENetHosts then I can connect to myself
>> fine, but I suspect that this is going to subtly upset the
>> auto-throttling (i.e. each ENetHost will try to throttle around
>> spikes caused by the other, since they don't share accounting)."
>>
>> See
>> http://lists.cubik.org/pipermail/enet-discuss/2004-December/000313.html
>>
>>
>>
>> On 8 November 2013 10:00, Ruud van Gaal <ruud at racer.nl> wrote:
>>
>>> Ah ok, but the concept behind Client & Server is that you have 2 hosts,
>>> right? A client host and a server host...
>>> Ruud
>>>
>>>
>>> On Fri, Nov 8, 2013 at 6:10 PM, Krasimir Marinov <krasi at jklsemi.com>wrote:
>>>
>>>> You won't hit this case unless you use *only one* ENetHost. If your
>>>> client and server are separate ENetHost(s) then there is no "loopback"
>>>> connect.
>>>>
>>>>
>>>> On Fri, Nov 8, 2013 at 7:02 PM, Ruud van Gaal <ruud at racer.nl> wrote:
>>>>
>>>>> That is strange, the check and refusal of that connection.
>>>>> One thing that might be different from my case is that I obtain the IP
>>>>> address of the localhost. So I setup a server at 192.168.0.10 for example,
>>>>> rather than 127.0.0.1.
>>>>> The connecting client then may or may not connect to 127.0.0.1 or
>>>>> 192.168.0.10.
>>>>> It might be interesting to see what the 4 variants do: 192.168.0.10
>>>>> connecting to 127.0.0.1 and its four variants (192/192, 192/127, 127/127,
>>>>> 127/192).
>>>>>
>>>>> Hm,
>>>>> Ruud
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 8, 2013 at 5:16 PM, Krasimir Marinov <krasi at jklsemi.com>wrote:
>>>>>
>>>>>> I decided to dig a bit deeper into this "issue" and here are my
>>>>>> findings:
>>>>>>
>>>>>> There is a special section in
>>>>>> protocol.c/enet_protocol_handle_connect()/row 302 that prevents from
>>>>>> connecting to our own host (loopback connect):
>>>>>>
>>>>>> 302 if (currentPeer -> address.port == host -> receivedAddress.port
>>>>>> &&
>>>>>>
>>>>>> 303 currentPeer -> connectID == command -> connect.connectID)
>>>>>> {
>>>>>>
>>>>>> 304 printf("enet_protocol_handle_connect(): loopback
>>>>>> connect = return NULL\n");
>>>>>>
>>>>>> 305 //return NULL;
>>>>>>
>>>>>>
>>>>>> 306 }
>>>>>> I've modified it with a printf() statement to debug.
>>>>>>
>>>>>> With the following test program when using the original version I'm
>>>>>> unable to connect to myself. With the modified ENet version I get two
>>>>>> connect events - one for the peer initiating connect and one for the peer
>>>>>> being connected.
>>>>>>
>>>>>> This is the output:
>>>>>>
>>>>>> Connecting peer 0x7fed91006000
>>>>>>
>>>>>> enet_protocol_handle_connect(): loopback connect = return NULL
>>>>>>
>>>>>> A new peer (0x7fed91006000) connected from 100007f:55555.
>>>>>>
>>>>>> A new peer (0x7fed910061d0) connected from 100007f:55555.
>>>>>>
>>>>>> And here is the program:
>>>>>>
>>>>>> #include <enet/enet.h>
>>>>>>
>>>>>> #include <stdio.h>
>>>>>>
>>>>>>
>>>>>> int main() {
>>>>>>
>>>>>> ENetAddress address;
>>>>>>
>>>>>> ENetHost *host;
>>>>>>
>>>>>> ENetPeer *peer;
>>>>>>
>>>>>> ENetEvent event;
>>>>>>
>>>>>>
>>>>>> enet_address_set_host(&address, "127.0.0.1");
>>>>>>
>>>>>> address.port = 55555;
>>>>>>
>>>>>>
>>>>>> host = enet_host_create (&address, 32, 1, 0, 0);
>>>>>>
>>>>>> peer = enet_host_connect(host, &address, 1, 0);
>>>>>>
>>>>>>
>>>>>> printf("Connecting peer %p\n", peer);
>>>>>>
>>>>>>
>>>>>> while (enet_host_service (host, & event, 100000) > 0) {
>>>>>>
>>>>>> switch (event.type) {
>>>>>>
>>>>>> case ENET_EVENT_TYPE_CONNECT:
>>>>>>
>>>>>> printf ("A new peer (%p) connected from %x:%u.\n",
>>>>>>
>>>>>> event.peer,
>>>>>>
>>>>>> event.peer -> address.host,
>>>>>>
>>>>>> event.peer -> address.port);
>>>>>>
>>>>>> /* Store any relevant client information here. */
>>>>>>
>>>>>> event.peer -> data = "Client information";
>>>>>>
>>>>>> break;
>>>>>>
>>>>>> case ENET_EVENT_TYPE_RECEIVE:
>>>>>>
>>>>>> printf ("A packet of length %lu containing %s was received from
>>>>>> %s on channel %u.\n",
>>>>>>
>>>>>> event.packet -> dataLength,
>>>>>>
>>>>>> event.packet -> data,
>>>>>>
>>>>>> event.peer -> data,
>>>>>>
>>>>>> event.channelID);
>>>>>>
>>>>>> /* Clean up the packet now that we're done using it. */
>>>>>>
>>>>>> enet_packet_destroy (event.packet);
>>>>>>
>>>>>> break;
>>>>>>
>>>>>>
>>>>>>
>>>>>> case ENET_EVENT_TYPE_DISCONNECT:
>>>>>>
>>>>>> if(event.peer->data)
>>>>>>
>>>>>> printf ("%p: %s disconected.\n", event.peer, event.peer ->
>>>>>> data);
>>>>>>
>>>>>> else
>>>>>>
>>>>>> printf("%p: disconnected\n", event.peer);
>>>>>>
>>>>>> /* Reset the peer's client information. */
>>>>>>
>>>>>> event.peer -> data = NULL;
>>>>>>
>>>>>> break;
>>>>>>
>>>>>> default:
>>>>>>
>>>>>> printf("default\n");
>>>>>>
>>>>>> break;
>>>>>>
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Krasimir
>>>>>>
>>>>>> On Thu, Nov 7, 2013 at 12:45 PM, Krasimir Marinov <krasi at jklsemi.com>wrote:
>>>>>>
>>>>>>> The code that you shared connects peers from 2 different ENetHosts.
>>>>>>>
>>>>>>> The pseudocode that I showed
>>>>>>>
>>>>>>> ENetAddress address;
>>>>>>> a.host = <localhost>
>>>>>>> a.port = <port>
>>>>>>>
>>>>>>> EnetHost *host = enet_host_create(&address, .....);
>>>>>>> enet_host_connect(host, &address, ...);
>>>>>>>
>>>>>>> tries to connect the host to itself. Notice that there is only one
>>>>>>> address and one host!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 7, 2013 at 12:08 PM, Andrew Fenn <andrewfenn at gmail.com>wrote:
>>>>>>>
>>>>>>>> I don't have any problems with a running a client / server on the
>>>>>>>> same
>>>>>>>> machine. My code is available here, it's unfinished overall however
>>>>>>>> the enet connection stuff has worked without problems for a long
>>>>>>>> time.
>>>>>>>>
>>>>>>>> https://github.com/andrewfenn/Hardwar
>>>>>>>> Server:
>>>>>>>> https://github.com/andrewfenn/Hardwar/blob/master/code/server/src/Server.cpp
>>>>>>>> Client:
>>>>>>>> https://github.com/andrewfenn/Hardwar/blob/master/code/client/tasks/src/NetworkTask.cpp
>>>>>>>>
>>>>>>>> On Thu, Nov 7, 2013 at 5:00 PM, Ruud van Gaal <ruud at racer.nl>
>>>>>>>> wrote:
>>>>>>>> > All I can say that in principle this works; I use this every day
>>>>>>>> (a single
>>>>>>>> > exe running both and a server and a client, where the client
>>>>>>>> connects to its
>>>>>>>> > own server).
>>>>>>>> > Ruud
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Wed, Nov 6, 2013 at 2:37 PM, Krasimir Marinov <
>>>>>>>> krasi at jklsemi.com> wrote:
>>>>>>>> >>
>>>>>>>> >> Hi,
>>>>>>>> >>
>>>>>>>> >> I’ve been trying to connect to the host:port that my ENetHost is
>>>>>>>> bound to,
>>>>>>>> >> i.e. connect and send to myself.
>>>>>>>> >> Unfortunately this almost immediately results in event
>>>>>>>> DISCONNECT.
>>>>>>>> >>
>>>>>>>> >> Looking at the archives I found the same problem raised 9 years
>>>>>>>> ago (see
>>>>>>>> >> below).
>>>>>>>> >>
>>>>>>>> >> Any reason for this behaviour?
>>>>>>>> >>
>>>>>>>> >> Regards,
>>>>>>>> >> Krasimir
>>>>>>>> >>
>>>>>>>> >> [ENet-discuss] Connecting to self.
>>>>>>>> >>
>>>>>>>> >> Adam D. Moss adam at gimp.org
>>>>>>>> >> Wed Dec 1 08:44:30 PST 2004
>>>>>>>> >>
>>>>>>>> >> Next message: [ENet-discuss] Connecting to self.
>>>>>>>> >> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>>>>>>>> >>
>>>>>>>> >> ________________________________
>>>>>>>> >>
>>>>>>>> >> Hi!
>>>>>>>> >> I have a funny problem. My app listens on a port and then
>>>>>>>> attempts
>>>>>>>> >> to connect to itself (for testing purposes, for now). But this
>>>>>>>> >> merely eventually causes a DISCONNECT (presumably time-out)
>>>>>>>> event,
>>>>>>>> >> with no CONNECT.
>>>>>>>> >>
>>>>>>>> >> However, if I launch a second process and do the connect from
>>>>>>>> >> there, the connection is fine.
>>>>>>>> >>
>>>>>>>> >> Am I being stupid for attempting to have a process be a client
>>>>>>>> >> of its own server, or is there some unexpected strangeness which
>>>>>>>> >> prevents an ENet server from being its own client?
>>>>>>>> >>
>>>>>>>> >> Thanks,
>>>>>>>> >> --Adam
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> _______________________________________________
>>>>>>>> >> ENet-discuss mailing list
>>>>>>>> >> ENet-discuss at cubik.org
>>>>>>>> >> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>>>> >>
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > ENet-discuss mailing list
>>>>>>>> > ENet-discuss at cubik.org
>>>>>>>> > http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>>>> >
>>>>>>>> _______________________________________________
>>>>>>>> ENet-discuss mailing list
>>>>>>>> ENet-discuss at cubik.org
>>>>>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ENet-discuss mailing list
>>>>>> ENet-discuss at cubik.org
>>>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ENet-discuss mailing list
>>>>> ENet-discuss at cubik.org
>>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> ENet-discuss mailing list
>>>> ENet-discuss at cubik.org
>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ENet-discuss mailing list
>>> ENet-discuss at cubik.org
>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>
>>>
>>
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20131112/8ddbf0e6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enet_loopback_connect.patch
Type: application/octet-stream
Size: 726 bytes
Desc: not available
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20131112/8ddbf0e6/attachment-0001.obj>
More information about the ENet-discuss
mailing list