[ENet-discuss] A query about channels

[Ruud van Gaal]

My idea of channels is that they separate streams of reliable packets. So
for example if you have 2 events, one being a chat message and the other
being a player damage event, you'd probably want both to get there reliably.
However, if you put both on different channels, a delayed chat message won't
interfere with the damage event, and your gameplay might suffer less if the
damage packet was delivered (and the chat failed the first time).

Cheers,
Ruud 

> -----Oorspronkelijk bericht-----
> Van: enet-discuss-bounces at cubik.org 
> [mailto:enet-discuss-bounces at cubik.org] Namens Alex Milstead
> Verzonden: Sunday, January 17, 2010 11:04
> Aan: ENet-discuss at cubik.org
> Onderwerp: [ENet-discuss] A query about channels
> 
> Hey all,
> 
> Is it possible for anyone to give a brief overview of the 
> feature purpose of channels within ENet? I'd like to discover 
> the real concept behind them to in/validate the idea I have 
> for using them. I don't want to abuse the channeling system 
> with what I intend to do, especially if they weren't meant for it.
> 
> Without loss of generality, I'd like to use different 
> channels to send different types of information. The 
> application I'm working with (like many who've posted 
> before), happens to be a fledgling online-game. I'd like to 
> be able to send different basic subsets of data via different 
> channels (e.g., login through channel 0, character lists 
> through channel 1, movement updates through 2, etc.). I'm 
> using common structs inside a wrapper library on both client 
> and server side applications, so it isn't a big deal to 
> capture the type/make-up of the struct on both ends (easily 
> done with a simple memcpy!). It seems as though structs are 
> the most efficient way of sending data back and forth between 
> apps. Is this idea of separation of information involved in 
> what channels were originally designed to handle (my hunch says no)?
> 
> Also, if different channels for different structs shouldn't 
> be my solution, does anyone have any advice on how I should 
> handle varying types of common information being sent to and fro?
> 
> Thanks in advance for any comments/advice/instruction.
> 
> Cheers,
> Alex
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss