[ENet-discuss] enet is dropping packets

[Stefan Lundmark]

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: 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
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>