[ENet-discuss] Removing Channels and Reliable Ordering

[Lee Salzman]

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.