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