[ENet-discuss] Removing Channels and Reliable Ordering

[Lee Salzman]

The bitmap is as good an idea as any. I really can't think of a better
way to do it offhand. It could be just wide enough to hide any latency
from stalling fresher packets that won't fit into it yet, but any packets 
fitting within that window could all be delivered out of order. When it
fills up completely you move the window down to handle the newer
packets. Then for stuff that scrolled off the window you can just
compare the sequence number and simply discard them as duplicates. That 
what you were thinking? Could use this for duplicate detection of 
unreliable packets without much trouble too, since it's already in place.

Lee

On Tue, Nov 18, 2003 at 10:55:18AM -0000, Jim Purbrick wrote:
> Thanks Lee.
> 
> It seems that a better way to do this is to move packets to a
> completedIncomingCommands queue when they're assembled. enet_peer_receive()
> just returns the front of the queue.
> 
> Delivering packets out of order adds another complication though. In order
> to discard duplicates I need to maintain a window of received reliable
> packets, rather than just the maximum sequence number delivered. I'm
> planning to do this with a scrolling bitfield which maintains an offset and
> a bitmap of received sequence numbers. Does this sound like the best plan,
> or should I piggyback on an existing window or data structure?
> 
> Cheers,
> 
> Jim.
> 
> > -----Original Message-----
> > From: Lee Salzman [mailto:lsalzman at telerama.com]
> > Sent: 17 November 2003 19:22
> > To: Discussion of the ENet library
> > Subject: Re: [ENet-discuss] Removing Channels and Reliable Ordering
> > 
> > 
> > There is one problem with that... packets will get stalled if they're
> > not first in the queue and there's a packet not completely 
> > assembled in
> > front. You need to scan the ENTIRE queue for any packets that are
> > assembled if you want to prevent the stalling.
> > 
> > Lee
> > 
> > On Mon, Nov 17, 2003 at 07:11:25PM -0000, Jim Purbrick wrote:
> > > Thanks Lee.
> > > 
> > > I now seem to have a working ENet mod with no channels and 
> > no stalling of
> > > reliable packets.
> > > 
> > > > Oh, I get you now! Well, in a way I'm almost tempted to support
> > > > unsequenced (un)reliable packets, but am not sure how much the
> > > > extra code would muck up the internals. Though, if there is a 
> > > > strong need from enough people, I could accomodate it.
> > > 
> > > No stalling seems to be a one-liner.
> > > 
> > > Line 197 in peer.c:
> > > 
> > >         if (incomingCommand -> fragmentsRemaining > 0 ||
> > >             incomingCommand -> reliableSequenceNumber > channel ->
> > > incomingReliableSequenceNumber + 1)
> > >           return NULL;
> > > 
> > > Becomes:
> > > 
> > >         if (incomingCommand -> fragmentsRemaining > 0)
> > >           return NULL;
> > > 
> > > You could stick a bool in the peer or host which enables or 
> > disables this
> > > check easily enough.
> > > 
> > > > But more or less, you would have to add two incoming 
> > command queues
> > > > (one for unreliable, one for reliable) on the peer. You 
> > would still
> > > > need to keep the reliable sequence numbers for identifying packets
> > > > during acknowledgement. enet_peer_receive() would need to 
> > be rewritten
> > > > to scan the two queues for any completely assembled 
> > packets. Finally,
> > > > you could just get rid of the channel ids and channels 
> > entirely. That 
> > > > would be about it. Shouldn't be too difficult.
> > > 
> > > The only other thing I needed to do was set the
> > > incomingReliableSequenceNumber of the peer to the sequence 
> > number of the
> > > connect message in enet_protocol_handle_connect.
> > > 
> > > I'll let you know how my testing goes tomorrow.
> > > 
> > > Cheers,
> > > 
> > > Jim.
> > 
> > 

> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss