[ENet-discuss] Connecting to self (resolved)

[Krasimir Marinov]

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