Thanks! I'm (extensively) using (and seriously load testing) the patched version for the last week or so and can confirm that it works. I *haven't* tested throttling though!
--Krasi On Mon, Nov 18, 2013 at 2:21 PM, Lee Salzman <[email protected]> wrote: > 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 > >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
