[ENet-discuss] Removing Channels and Reliable Ordering

[Lee Salzman]

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.

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.

Lee

On Mon, Nov 17, 2003 at 04:17:26PM -0000, Jim Purbrick wrote:
> Hi Lee,
> 
> Thanks for getting back to me.
> 
> > Channel 255 is where connection related commands (like ping, connect,
> > disconnect, throttle configure, etc.) are sent. That way it doesn't
> > mess with the sequencing on other channels.
> 
> OK, cool.
>  
> > Now, if you're not using channels or reliable packets, it might be
> > easier to not use ENet and just use plain UDP, but then again, there's
> > still a lot of value ENet adds even in that situation. YMMV.
> 
> I _AM_ using reliable packets, I just have a different way of dealing with
> out of order delivery. If 2 reliable events are not causally connected I
> know that I don't have to have stall delivery of 1 while I wait for the
> other. The code that determines causal ordering is above ENet, so I just
> want ENet to give me reliable packets as soon as they're reassembled. I
> still want ENet to resend lost fragments and send acknowledgements and all
> the rest of it, just not stall delivery.
>  
> > But in any case, there shouldn't be any need to modify ENet - just 
> > specify 1 channel per connection and don't send any reliable packets,
> > and you won't suffer any overhead from either of them. The sequencing 
> > of unreliable packets imposes no speed hit whatsoever, since packets
> > that would have to be delivered out-of-order are simply discarded.
> 
> I could just use 1 channel and find and remove the stalling code, but I
> don't want to waste bandwidth specifying channels when I'm not using any
> channels. It sounds like I could effectively send all data on channel 255,
> which would allow me to bin the channel bytes, does this sound OK?
> 
> > So, in short:
> > 1) Don't modify ENet! It's not necessary!
> 
> I think it is.
> 
> > 2) Allocate only 1 channel per client.
> 
> I'd rather not waste the bandwidth.
> 
> > 3) Send your packets as unreliable.
> 
> I'd like some of them to be reliable, but I don't want stalling.
> 
> Cheers,
> 
> Jim.
>