[ENet-discuss] enet is dropping packets

[Soren Dreijer]

> Eh, it is an upper bound on the wait time if nothing is received!

Are you absolutely sure about this? I seem to recall back when I started
with enet that calling enet_host_service() with a high timeout would cause
huge delays in receiving packets because enet_host_service() wouldn't return
until the timeout has expired. I'll verify that again, but I thought that
was how it worked at least.

I find it hard to believe that my dedicated thread cannot service packets
for 124 users (who aren't really sending THAT much data) if the thread is
running as fast as it can.

> -----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