[ENet-discuss] Connecting to self (resolved)
Krasimir Marinov
krasi at jklsemi.com
Mon Nov 18 04:33:17 PST 2013
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 <lsalzman at gmail.com> 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 <lsalzman at gmail.com> 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 <krasi at jklsemi.com>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 <lsalzman at gmail.com>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 <erwin.coumans at gmail.com
>>>> > 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 <ruud at racer.nl> 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 <krasi at jklsemi.com>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 <ruud at racer.nl> 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 <krasi at jklsemi.com
>>>>>>>> > 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 <
>>>>>>>>> krasi at jklsemi.com> 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 <
>>>>>>>>>> andrewfenn at gmail.com> 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 <ruud at racer.nl>
>>>>>>>>>>> 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 <
>>>>>>>>>>> krasi at jklsemi.com> 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
>>>>>>>>>>> >> ENet-discuss at cubik.org
>>>>>>>>>>> >> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>>>>>>> >>
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>> > ENet-discuss mailing list
>>>>>>>>>>> > ENet-discuss at cubik.org
>>>>>>>>>>> > http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>>>>>>> >
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> ENet-discuss mailing list
>>>>>>>>>>> ENet-discuss at cubik.org
>>>>>>>>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ENet-discuss mailing list
>>>>>>>>> ENet-discuss at cubik.org
>>>>>>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> ENet-discuss mailing list
>>>>>>>> ENet-discuss at cubik.org
>>>>>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ENet-discuss mailing list
>>>>>>> ENet-discuss at cubik.org
>>>>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ENet-discuss mailing list
>>>>>> ENet-discuss at cubik.org
>>>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ENet-discuss mailing list
>>>>> ENet-discuss at cubik.org
>>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> ENet-discuss mailing list
>>>> ENet-discuss at cubik.org
>>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ENet-discuss mailing list
>>> ENet-discuss at cubik.org
>>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>>
>>>
>>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20131118/39114f38/attachment-0001.html>
More information about the ENet-discuss
mailing list