[ENet-discuss] Connecting to self (resolved)
Ruud van Gaal
ruud at racer.nl
Fri Nov 8 10:00:11 PST 2013
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20131108/375bb17a/attachment.html>
More information about the ENet-discuss
mailing list