Happy to help. ENET rocks! :-)
On Mon, Dec 15, 2014 at 9:29 PM, Laftur Jeremy <[email protected]> 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 > <[email protected]> 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 <[email protected]> > > 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 > >> <[email protected]> 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 > >> > <[email protected]> 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 > >> >> <[email protected]> > >> >> 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 > >> >>> <[email protected]> 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 > >> >>> > <[email protected]> > >> >>> > 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 > >> >>> >> [email protected] > >> >>> >> http://lists.cubik.org/mailman/listinfo/enet-discuss > >> >>> > > >> >>> > > >> >>> > _______________________________________________ > >> >>> > ENet-discuss mailing list > >> >>> > [email protected] > >> >>> > http://lists.cubik.org/mailman/listinfo/enet-discuss > >> >>> > > >> >>> _______________________________________________ > >> >>> ENet-discuss mailing list > >> >>> [email protected] > >> >>> http://lists.cubik.org/mailman/listinfo/enet-discuss > >> >> > >> >> > >> > > >> > _______________________________________________ > >> > ENet-discuss mailing list > >> > [email protected] > >> > http://lists.cubik.org/mailman/listinfo/enet-discuss > >> > > >> _______________________________________________ > >> ENet-discuss mailing list > >> [email protected] > >> http://lists.cubik.org/mailman/listinfo/enet-discuss > > > > > > _______________________________________________ > > ENet-discuss mailing list > > [email protected] > > http://lists.cubik.org/mailman/listinfo/enet-discuss > > > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
