[ENet-discuss] totally flush the outgoing commands list

Lee Salzman lsalzman at gmail.com
Wed Sep 11 03:28:35 PDT 2013


What you may be running into is that sometimes enet_host_service() may simply pull some packets out of the receive queue without hitting the socket. So if you only call enet_host_service() once a frame, and multiple packets are coming in each frame, then you will end up continually running behind the socket.

There is a function enet_host_check_events() designed to work around this problem - it just returns events from the event queue and instead of hitting the socket when the event queue is empty, it just does nothing. So assuming you start with an empty event queue on each frame, first you call enet_host_service() which will do its thing to the socket, and then continually call enet_host_check_events() till there are no more events left.

On 09/11/2013 12:58 PM, Arnaud Blanchard wrote:
> Hi,
>
> Each time we use enet, we have the same problem when we have lot of data to send.
> Eventhough we call very regularly enet_host_service the outgoing command list is continuously growing and the lag to retrieve the data is continuously increasing. Even using enet_host_flush does not solve the problem.
>
> We wonder if it can be a kind of timeout somewhere or a limit in the number of packet sent in one shout. Anyway, the only solution (see below) that we have found is to loop on calling enet_host_service until the list is empty, but it is not very clean or satisfactory.
>
> Any explanation ?
>
> Thank you for your help, best regards,
>
> Arnaud Blancahrd
>
>
> for(i=0;i<host->peerCount;i++)
> {
>     while ( !enet_list_empty(&(peers[i].outgoingReliableCommands))
>             || !enet_list_empty(&(peers[i].outgoingUnreliableCommands)))
>             {
>                 enet_host_service(0);
>             }
> }
>



More information about the ENet-discuss mailing list