[ENet-discuss] Unreliable Data Loss

[Lee Salzman]

    ENet delivers packets in-order. So this means if you send out 
two unreliable packets, say A and B with A sent before B, then if B 
arrives first ENet is just going to go ahead and deliver it. Then 
when A arrives, since it is now out of sequence, it will just get 
dropped. 

    If the packets are both received in the same call to 
enet_host_service(), however, they will be reordered in the queue and
neither will be dropped. So, the more often you service the host the 
more likely this situation will occur, since this will prevent ENet 
from reordering packets in the queue without resorting to dropping them.
It tries to deliver the unreliable packets to the user as fast as
they're demanded, so sometimes this requires drastic measures.
That's just how the cookie crumbles; lower latency is lower reliability.

Lee

On Tue, Jan 27, 2004 at 05:25:17PM -0000, Jim Purbrick wrote:
> I've got a simple Windows test client sending 1 KB/s of unreliable data over
> loopback to a server which sends 100 copies of the data back unreliably to
> the client. Enet is set up with no throttling in either direction. 
> 
> If the client process has the focus I experience no data loss, if the server
> has focus, the server receives all the data sent by the client, but the
> client only receives 40% of the data sent in reply.
> 
> The machine is only using 4% CPU, so the client doesn't seem to be starved
> of CPU. I've added some logging and it looks like the server is sending
> blocks of 100 unreliable packets. When the client has focus it receives all
> 100 packets. Without focus it only receives the first few packets from each
> block.
> 
> Any Idea what's causing this? Presumably in a low-load, loopback test like
> this I shouldn't see any packet loss.