[ENet-discuss] Unreliable Data Loss

[Jim Purbrick]

He he, that's exactly what I've done! Maybe I should have just pestered you
for unsequenced reliable and unreliable transmission a bit more before I
started modifying ENet. If I could have persuaded you to add those features
I could have just used ENet as a library rather than converting it to C++ so
I could modify it. The only other plan I have for my version of ENet is
optional priority support, any plans for that ;-)

My reliable delivery scheme is very similar, except the window only moves
when the first packet in the window arrives. Packets below the window must
be duplicates, packets beyond the window are stalled. What window sizes are
you using?

Anyway, the problems I'm getting with packet loss won't be solved with your
changes as your version of ENet is now the same as mine for unreliable
transmission (although I haven't got any bug fixes you've made since 17
November last year - any biggies I need?).

I think the problem is something to do with Windows scheduling as everything
is fine when the client has focus and so gets a priority boost. 

I've done some more tests and when sending 1 Byte/s or 10 Bytes/s I get 0
packet loss, even when the client doesn't have focus. When sending 100
Bytes/s to 1000 Bytes/s packet loss increases with data rate. 

I wondered whether it was because the server was trying to send 100 KB to
the client in a single service call and so overloading the client UDP buffer
(how big are UDP buffers in Windows?). I tried rate limiting ENet to
100KB/s, but the problem remained.

I also tried increasing the client send rate to see if I could overload the
server in the same way, but it kept up fine. Weird.

Anyway, I can't spend any more time looking at this, just thought I'd share
my results with you. I'll integrate ENet with the game and see what real
world results I get.

> -----Original Message-----
> From: Lee Salzman [mailto:lsalzman at telerama.com]
> Sent: 28 January 2004 14:53
> To: Discussion of the ENet library
> Subject: Re: [ENet-discuss] Unreliable Data Loss
> 
> 
> Well, I used the same sliding bit window scheme we talked 
> about before.
> But since I'm only handling unreliable packets, if the packet is below
> the window, it simply gets dropped. If the packet is above the window,
> the window just gets moved to the next aligned window that encompasses
> the packet. Any other stuff within the window just gets bit diddled.
> This means there still could be a little order-related dropping on
> window boundaries, but overall it should be hugely less.
> 
> Once received, I just stuff the packets at the front of the 
> appropriate
> channel queues so they don't mess with ordering.
> 
> Supporting reliable packets too would have made it much bigger than I
> would have liked, but for now I can handle the unreliable, unsequenced
> packets pretty cleanly with only a few extra lines of code.
> 
> Lee
> 
> On Wed, Jan 28, 2004 at 10:53:46AM -0000, Jim Purbrick wrote:
> > Hi Lee,
> > 
> > How did you do it? Just pass any received unreliable packet 
> to the user? Do
> > you do duplicate detection? 
> > 
> > As you may remember I'm modifying my version of ENet to 
> deliver reliable and
> > unreliable packets unsequenced. In both cases I use a 
> sliding bit window to
> > check whether I've received a packet before and if not just 
> deliver it to
> > the user.
> > 
> > > -----Original Message-----
> > > From: Lee Salzman [mailto:lsalzman at telerama.com]
> > > Sent: 27 January 2004 19:10
> > > To: Discussion of the ENet library
> > > Subject: Re: [ENet-discuss] Unreliable Data Loss
> > > 
> > > 
> > > Okay, since I felt particularly inspired by this example, I added
> > > unreliable, UNSEQUENCED packets to ENet (no support for reliable,
> > > unsequenced packets, though). :)
> > > 
> > > This should be in for 1.0.
> > > 
> > > Lee
> > > 
> > > On Tue, Jan 27, 2004 at 01:30:43PM -0500, Lee Salzman wrote:
> > > > I should also add that I'm not entirely certain the 
> > > sequencing is the
> > > > problem, but it's the only thing that I can think of that 
> > > would cause
> > > > it. You're probably pumping out packets really fast, and 
> > > your network
> > > > stack is probably playing nasty games with the ordering of 
> > > them, which
> > > > is not playing nice with ENet. You can test this by 
> > > inserting a small 
> > > > delay after each call to enet_host_service() (maybe 
> 30-50 ms?) on 
> > > > either the client or server end and seeing if the loss 
> rate lowers.
> > > > 
> > > > Lee
> > > > 
>