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 <[email protected]> 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 <[email protected]>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 <[email protected]>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 <[email protected]> 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 <[email protected]> >>> 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 >>> >> [email protected] >>> >> http://lists.cubik.org/mailman/listinfo/enet-discuss >>> >> >>> > >>> > >>> > _______________________________________________ >>> > ENet-discuss mailing list >>> > [email protected] >>> > http://lists.cubik.org/mailman/listinfo/enet-discuss >>> > >>> _______________________________________________ >>> ENet-discuss mailing list >>> [email protected] >>> http://lists.cubik.org/mailman/listinfo/enet-discuss >>> >> >> > > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss > >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
