[ENet-discuss] enet is dropping packets

[Soren Dreijer]

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: enet-discuss-bounces at cubik.org [mailto:enet-discuss-
> bounces at cubik.org] 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
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss