[ENet-discuss] enet is dropping packets

[Lee Salzman]

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