Oh boy. *facepalm* I found the problem. After stepping through enet_protocol_handle_connect() in the debugger, I noticed that there weren't any peers available in the 'peers' array.
And sure enough, I'd called enet_host_create() with a peerCount of 99 (set way back in the day when I originally switched to enet). That would explain why things went haywire as more users came online. Thanks to everyone for their suggestions. / Soren > -----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
