[ENet-discuss] Connecting to self (resolved)
Ruud van Gaal
ruud at racer.nl
Fri Nov 8 12:20:44 PST 2013
Ah, but the idea seems fundamentally flawed; one host (which is either
client or server) means client connecting to client, or server connecting
to server. I'd say this working would be a coincidence rather than by
design.
Ruud
On Fri, Nov 8, 2013 at 8: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20131108/9df230cb/attachment-0001.html>
More information about the ENet-discuss
mailing list