[ENet-discuss] Connecting to self (resolved)
Krasimir Marinov
krasi at jklsemi.com
Fri Nov 8 08:40:37 PST 2013
I'd be very thankful if someone, familiar with this part of the code,
express opinion about the reason for this limitation and the safety of the
patch.
On Fri, Nov 8, 2013 at 6: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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20131108/eee3eb39/attachment-0001.html>
More information about the ENet-discuss
mailing list