For better or worse I committed a version of this fix to the repo. I didn't have time to actually test it out, though, so I will, uh, let you guys beta-test this one. ;)
On Tue, Nov 12, 2013 at 12:45 PM, Lee Salzman <[email protected]> wrote: > That's more or less the check I had in mind. In theory the peer > bookkeeping should work fine. But that's theory. It is the practice that > must be verified. :) > > > On Tue, Nov 12, 2013 at 12:31 PM, Krasimir Marinov <[email protected]>wrote: > >> Thanks Lee! >> >> That sheds some light on this check. I've applied this patch in order to >> allow loopback connects: >> >> >> --- enet-1.3.9/protocol.c 2013-08-18 17:16:04.000000000 +0300 >> >> +++ enet-1.3.9.mod/protocol.c 2013-11-12 12:21:18.000000000 +0200 >> >> @@ -299,7 +299,10 @@ >> >> else >> >> if (currentPeer -> address.host == host -> receivedAddress.host) >> >> { >> >> - if (currentPeer -> address.port == host -> >> receivedAddress.port && >> >> + /* This check prevents duplicate *connection attempts* >> resulting >> >> + from a connection packet being retransmitted */ >> >> + if (currentPeer -> state != ENET_PEER_STATE_CONNECTING && >> >> + currentPeer -> address.port == host -> >> receivedAddress.port && >> >> currentPeer -> connectID == command -> connect.connectID) >> >> return NULL; >> >> >> >> Is this the (ENET_PEER_STATE_CONNECTING) check you mentioned? >> >> As for the throttling, based on my shallow view of the current >> implementation, I thought it won't be messed, because the >> throttling-related bookkeeping is *per peer*, so it won't matter where the >> peer comes from (localhost, another host, or the loopback connect). Am I >> right? >> >> >> >> On Tue, Nov 12, 2013 at 11:27 AM, Lee Salzman <[email protected]> wrote: >> >>> Sorry for the late response, as I was away for the weekend. After >>> looking into it, that check ultimately prevents duplicate *connection >>> attempts* resulting from a connection packet being retransmitted. There is >>> a quite easy work-around for it in theory, by just adding a check for the >>> ENET_PEER_STATE_CONNECTING state (which indicates the sender of the connect >>> attempt) and skipping it if it is found. What I don't know is if or how >>> this will mess up the peer management for things like throttling when there >>> are two peers on a single host representing both ends of a single >>> connection, if said loopback connections where host and client are the same >>> are allowed to proceed. >>> >>> An enterprising person would have to experiment and verify everything >>> works fine, but I myself won't have time to futz with this till the weekend >>> at best. >>> >>> >>> On Fri, Nov 8, 2013 at 9: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 >>> >>> >> >> _______________________________________________ >> 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
