You're already using a reliable UDP channel, which are inherently using several "back and forths". If you think that's too much overhead (I honestly doubt that will be much of a problem for you), then you probably shouldn't be using reliable UDP in the first place and just use straight up UDP.
> -----Original Message----- > From: [email protected] [mailto:enet-discuss- > [email protected]] On Behalf Of Emmanuel Rivoire > Sent: Thursday, May 24, 2012 10:08 AM > To: Discussion of the ENet library > Subject: Re: [ENet-discuss] Questioning a server without connecting to it > > Hello, > > because without this, it'd require at least 2 back & forth instead of > just 1 to get the needed info, + maybe some local extra processing > for the peer creation/destruction, so it'd be less efficient & > slower, which can be problematic in case there's a lot of online servers. > Plus, in case the server is full, I don't know how react the server > to a peer connection request. If it just times out, it's too slow to > get the result, and I can't grab the status info. > > At 22:00 24/05/2012, you wrote: > >Why do you want to do that? You're already talking about a > request/response > >flow, which only makes sense if you first establish a connection with the > >server and then wait for a response. > > > >If you don't want to keep the ENetPeer around on the server, then close it > >gracefully with enet_peer_disconnect() after you've sent the response. > > > _______________________________________________ > 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
