[ENet-discuss] Removing Channels and Reliable Ordering

[Jim Purbrick]

Thanks Lee,

I've got the bitmap for reliable packets done. 

I think this may allow me get away with having each packet carry a single
sequence number.

Unreliable packets are assigned the next unreliable sequence number. This is
only used for duplicate detection. The receiver checks its unreliable bitmap
and throws the packet away as a duplicate if the bit for its sequence number
is set or its sequence number is below the window. If its sequence number is
above the window the packet it stalled until the window scrolls far enough.
Otherwise the packet is delivered and the bit is set.

Reliable packets are treated the same way, they are assigned the next
reliable sequence number and the sender checks against the reliable bitmap.

Unreliable packets are not stalled on reliable packets, so they don't need
to carry a reliable sequence number.

Sequence numbers are just used for duplicate detection and the application
does causal ordering.

Does that sound OK?

I may be able to use the bitmaps to do SACK too, but that is getting a bit
ahead of myself. Does ENet currently do TCP style ACKs where it just
advertises the sequence number of the first missing data?

> -----Original Message-----
> From: Lee Salzman [mailto:lsalzman at telerama.com]
> Sent: 18 November 2003 15:38
> To: Discussion of the ENet library
> Subject: Re: [ENet-discuss] Removing Channels and Reliable Ordering
> 
> 
> 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
> 
>