[ENet-discuss] Removing Channels and Reliable Ordering

[Jim Purbrick]

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.

> On Mon, Nov 17, 2003 at 10:10:55AM -0000, Jim Purbrick wrote:
> > Hi All,
> > 
> > First of all, thanks for ENet! It does 90% of what I want 
> and has been
> > really easy to integrate with the system I'm working on.
> > 
> > The first major modification I'm trying to make to ENet is to remove
> > channels and reliable ordering. I'm using the sufficient 
> causal ording
> > mechanisms used on PARADE and MASSIVE-3 to avoid stalling on missing
> > reliable messages, so don't need multiple channels and 
> don't want any
> > reliable message stalling.
> > 
> > I've changed the channel array in ENetPeer to be a single 
> channel by value
> > and have trivially replaced the code that finds the correct 
> channel in a
> > peer. However, I've noticed that the peer itself also 
> contains sequence
> > number variables that are used when a special ChannelID of 0xFF is
> > specified. Can anyone shed some light on what is happening 
> here? Are these
> > variables redundant when no channels are used? What are 
> they used for? Am I
> > going to still need a special ChannelID flag in the data 
> structures even
> > when the channels are removed?
> > 
> > The other question I have is how to go about removing the 
> stalling of
> > reliable messages. I'd like all messages to be delivered to 
> the application
> > as soon as they have been re-assembled.
> > 
> > Thanks for your help and thanks for ENet!
> > 
> > Cheers,
> > 
> > Jim.
> > _______________________________________________
> > ENet-discuss mailing list
> > ENet-discuss at cubik.org
> > http://lists.cubik.org/mailman/listinfo/enet-discuss
>