[ENet-discuss] Unreliable Data Loss

[Lee Salzman]

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
> > >