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