[ENet-discuss] Removing Channels and Reliable Ordering

[Jim Purbrick]

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