Ah, but the idea seems fundamentally flawed; one host (which is either client or server) means client connecting to client, or server connecting to server. I'd say this working would be a coincidence rather than by design.
Ruud On Fri, Nov 8, 2013 at 8:45 PM, Erwin Coumans <[email protected]>wrote: > > I suppose Krasimir wants to use a single ENetHosts > for server and client for this reason: > > "If I switch to two separate ENetHosts then I can connect to myself > fine, but I suspect that this is going to subtly upset the > auto-throttling (i.e. each ENetHost will try to throttle around > spikes caused by the other, since they don't share accounting)." > > See > http://lists.cubik.org/pipermail/enet-discuss/2004-December/000313.html > > > > On 8 November 2013 10:00, Ruud van Gaal <[email protected]> wrote: > >> 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 >> >> > > _______________________________________________ > 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
