[ENet-discuss] Connecting to self (resolved)

Ruud van Gaal ruud at racer.nl
Fri Nov 8 09:02:23 PST 2013


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20131108/a6ce4eaf/attachment.html>


More information about the ENet-discuss mailing list