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
