Glad you found out what it was and let us know!
/Stefan
On 2012-06-20 08:32, Soren Dreijer wrote:
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
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
