[ENet-discuss] Connect event doesn't fire

Mon Dec 15 12:33:04 PST 2014

Happy to help. ENET rocks! :-)

On Mon, Dec 15, 2014 at 9:29 PM, Laftur Jeremy <laftur.jeremy at gmail.com>
wrote:
>
> 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
> >
> _______________________________________________
> 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/20141215/f8835b9d/attachment.html>