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
