[ENet-discuss] Connecting to self (resolved)
Krasimir Marinov
krasi at jklsemi.com
Fri Nov 8 09:10:06 PST 2013
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20131108/4aa4ed88/attachment-0001.html>
More information about the ENet-discuss
mailing list