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
