So, after digging around in the source a bit, I remember what the issue was with enet_host_service(): since enet isn't thread-safe, I have to dispatch packets on the same thread that calls enet_host_service(), so if I specify a large timeout value and no packets are received, then I won't be able to send packets either (since I cannot call enet_peer_send() until enet_host_service() has returned).
With that said, it looks like you're right that enet_host_service() returns as soon as there's a new event. I don't think I need to manually call enet_host_check_events() since enet_host_service() already does that under the hood whenever it receives data. I just verified that my process is NOT spinning when I'm experiencing this issue (i.e. packets getting dropped in the kernel), so beats me why enet is unable to process packets fast enough... > -----Original Message----- > From: [email protected] [mailto:enet-discuss- > [email protected]] On Behalf Of Lee Salzman > Sent: Tuesday, June 19, 2012 7:50 AM > To: Discussion of the ENet library > Subject: Re: [ENet-discuss] enet is dropping packets > > Eh, it is an upper bound on the wait time if nothing is received! > > If no event is ready to be delivered, it will just keeping waiting till there is an > event until it hits that 1ms. > > However, for cases where enet_host_service() is not flexible enough with > respect to timeouts, there is enet_host_check_events(). > > enet_host_check_events() ONLY dispatches any queued up events, without > ever touching the socket. > > So a typical usage is to first call enet_host_service() to do any necessary > socket stuff for this tick, then call enet_host_check_events() repeatedly until > there's no event left. Then you know the you've done everything you can for > this tick. Like so: > > for(bool serviced = false;;) > { > ENetEvent event; > if(!serviced) { if(enet_host_service(host, &event, timeout) <= 0) break; > serviced = true; } > else if(enet_host_check_events(host, &event) <= 0) break; > switch(event.type) > { > ... > } > } > > Also with respect to load, if your CPU utilization is getting really high and as a > result you are not servicing ENet often enough, ENet will interpret this as > extreme connection degradation, and throttle back stuff a ton. In that case, > the problem would not be ENet, it would be rather the code that is eating up > all the CPU. > > On 06/19/2012 09:50 PM, Soren Dreijer wrote: > > Hi there, > > > > I've recently run into an issue with my enet-powered server. When the > server > > gets under heavy load, I'm starting to see unsuccessful connection > attempts > > to the server. I've used tcpdump on the box and I see the enet connection > > packets coming in, but they're never processed by the server and the > > connection is never established. > > > > Looking at /proc/net/udp, I see a large number of dropped packets (>1000) > > and I'm guessing that's the issue. That is, I'm thinking enet isn't reading > > the packets from the UDP receive buffer fast enough and the kernel ends > up > > dropping the new packets. > > > > One thing I can do is to increase ENET_HOST_RECEIVE_BUFFER_SIZE, of > course, > > but I'm more worried why the server is already bogged down with only > about > > 124 clients connected. > > > > That leads me to enet_host_service(). I'm running the enet event loop in a > > dedicated thread and I specify a timeout of 1ms whenever I call > > enet_host_service() to avoid the event loop thread spinning 100% CPU in > case > > there's nothing to read. I assume that means I will only read one event per > > 1ms, right? > > > > Is there a way to improve that, i.e. have enet_host_service() wait _up to_ > > 1ms, but otherwise return as soon as there is data to process? It seems a > > little backwards to me that the timeout value isn't just an upper bound on > > the wait time in case nothing is received. > > > > Cheers, > > Soren > > _______________________________________________ > 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
