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);
}
}
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
