[ENet-discuss] Connect event doesn't fire

[Laftur Jeremy]

Oh, I see now. This crossed my mind, that the client might should not
exit immediately when it fires the connect event, so at one point I
had the client sleep for 10 seconds before breaking to give the server
time to acknowledge.
I see now why that didn't work. ENet needs me to continue to call
enet_host_service to complete the connection.

Thank you so much, Pablo! You're gold. :D

On Mon, Dec 15, 2014 at 3:15 PM, Pablo de Heras Ciechomski
<pablo.deheras at gmail.com> wrote:
> Ok so let's dance ;-) I downloaded your code, compiled and ran it. Indeed as
> you have it you exit immediately upon a connect event on the client side,
> this does not mean the server yet received your connect and immediately you
> exit. I removed the break here and it works as it should. That is the server
> gets the connect event "immediately".
>
> ENetEvent event;
> for(;;) {
> int ret = enet_host_service(client, &event, 1000);
> if(ret < 0) throw std::runtime_error("enet_host_service failed");
> if(event.type == ENET_EVENT_TYPE_NONE) {
> std::cout << "ENET_NONE\n";
> }
> else if(event.type == ENET_EVENT_TYPE_CONNECT) {
> std::cout << "ENET_CONNECT\n";
> // Sending a packet causes the connection to be recognized on the server
> end. Uncomment the following 3 lines to observe the behavior.
> //ENetPacket * packet = enet_packet_create("a", 1,
> ENET_PACKET_FLAG_RELIABLE);
> //enet_peer_send(peer, 0, packet);
> //enet_host_flush(client);
> I changed this removing the break -> //break;
> }
> else if(event.type == ENET_EVENT_TYPE_RECEIVE) {
> std::cout << "ENET_RECEIVE\n";
> }
> else if(event.type == ENET_EVENT_TYPE_DISCONNECT) {
> throw std::runtime_error("Connection failed");
> }
> }
>
> On Mon, Dec 15, 2014 at 8:50 PM, Laftur Jeremy <laftur.jeremy at gmail.com>
> wrote:
>>
>> Here is the new client.cpp:
>>
>> http://dpaste.com/3VWDWK7.txt
>>
>> I added enet_host_flush on line 14, immediately after
>> enet_host_connect and the check for a NULL peer, like you have in your
>> code example, but the server still does not fire the connect event.
>>
>> Could you confirm that the platform tests you performed used the code
>> I provided and not your interpretation of my code? I am running this
>> on ArchLinux, kernel version 3.17.6-1, ENet version 1.3.12-1
>>
>> On Mon, Dec 15, 2014 at 1:57 PM, Pablo de Heras Ciechomski
>> <pablo.deheras at gmail.com> wrote:
>> > Ah I see now in your source. You have to do the host_flush like I have
>> > provided here after the enet_host_connect on the client and not inside
>> > the
>> > event loop itself. What you did is backwards logic as you are waiting
>> > for an
>> > event to force that event. The host service loop is just an event pump.
>> >
>> > Hope that clears it up.
>> >
>> > Pablo
>> >
>> > On Mon, Dec 15, 2014 at 7:45 PM, Pablo de Heras Ciechomski
>> > <pablo.deheras at gmail.com> wrote:
>> >>
>> >> Indeed that is strange. I have correct behaviour on 3 platforms
>> >> Windows,
>> >> Mac and iPad using the flush command. Meaning that I immediately get a
>> >> connect event on the server upon the flush and do not have to send a
>> >> packet
>> >> or otherwise to force it from the client.
>> >>
>> >>   ENetAddress address;
>> >>   enet_address_set_host(&address,m_peerAddress.m_str);
>> >>   address.port=m_peerPort;
>> >>   m_peer=enet_host_connect(m_host,&address,2,0);
>> >>   if (m_peer==0)
>> >>   {
>> >>     return;
>> >>   }
>> >>   enet_host_flush(m_host);
>> >>
>> >> Pablo
>> >>
>> >> On Mon, Dec 15, 2014 at 7:38 PM, Laftur Jeremy
>> >> <laftur.jeremy at gmail.com>
>> >> wrote:
>> >>>
>> >>> Pablo, it is my understanding that enet_host_service also would do
>> >>> this, but to test it, I called enet_host_flush immediately after
>> >>> enet_host_connect in the client app. The result is the same. The
>> >>> server does not fire the connect event unless the client sends an ENet
>> >>> packet after connecting.
>> >>> Maybe i misunderstand you. What do you mean by "The behaviour that you
>> >>> are seeking will be the same."?
>> >>>
>> >>> On Mon, Dec 15, 2014 at 3:35 AM, Pablo de Heras Ciechomski
>> >>> <pablo.deheras at gmail.com> wrote:
>> >>> > Or you simply do an enet_host_flush(theHost) in your client app,
>> >>> > which
>> >>> > will
>> >>> > force the connect event. The behaviour that you are seeking will be
>> >>> > the
>> >>> > same.
>> >>> >
>> >>> > Pablo
>> >>> >
>> >>> > On Mon, Dec 15, 2014 at 5:51 AM, Laftur Jeremy
>> >>> > <laftur.jeremy at gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> I'm new to ENet, and I'm excited to use it in my projects. I made
>> >>> >> simple server and client programs to test it out and to make sure I
>> >>> >> understood how to use it.
>> >>> >>
>> >>> >> You may follow this link to view my server code:
>> >>> >>
>> >>> >> http://dpaste.com/2JW0DYE.txt
>> >>> >>
>> >>> >> ... And the client code is here:
>> >>> >>
>> >>> >> http://dpaste.com/1CKC6DC.txt
>> >>> >>
>> >>> >>
>> >>> >> The client program appears to function as expected, but the server
>> >>> >> program isn't firing the connect event for some reason. After
>> >>> >> combing
>> >>> >> the documentation and tutorials for more time than I'd care to
>> >>> >> admit,
>> >>> >> I finally decided to try to send a packet from the client to see if
>> >>> >> that did anything.
>> >>> >>
>> >>> >> It turns out that the server program waits to fire the connect
>> >>> >> event
>> >>> >> until the client actually sends a packet over the new connection.
>> >>> >> You
>> >>> >> may observe this behavior by uncommenting the indicated lines in
>> >>> >> the
>> >>> >> client program source.
>> >>> >>
>> >>> >> I would first like to know if my example programs exhibit the same
>> >>> >> behavior for anyone else. If so, I would like to know if the
>> >>> >> behavior
>> >>> >> is intended, and if so, I would like to know the reason for that,
>> >>> >> and
>> >>> >> I would suggest that the documentation provide some advice on this,
>> >>> >> as
>> >>> >> it has confused me greatly. Thanks so much for any help anyone can
>> >>> >> provide. You're the gold of the Internet just for being available
>> >>> >> to
>> >>> >> help.
>> >>> >> _______________________________________________
>> >>> >> 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
>