[ENet-discuss] A query about channels

[Ruud van Gaal]

I thought that unreliable packets would get through, even if reliable
messages are sent on the same channel inbetween?
I can see the need for reliable packets to be sequenced, thus delayed, but
unreliable packets coming in shouldn't need to be delayed by a reliable
packet inbetween (on the same channel), should it?

If so, I will make adjustment to put all my reliable packets on another
channel (I currently just use 1 channel).

Ruud 

> -----Oorspronkelijk bericht-----
> Van: enet-discuss-bounces at cubik.org 
> [mailto:enet-discuss-bounces at cubik.org] Namens Lee Salzman
> Verzonden: Sunday, January 17, 2010 16:56
> Aan: Discussion of the ENet library
> Onderwerp: Re: [ENet-discuss] A query about channels
> 
> Yes, it's not really about sending different types of data, 
> so much as it is differing latency needs of data. If I am 
> sending truckloads of unreliable packets on one channel, 
> sending even occasional reliable messages in that channel 
> might cause a stall, so segregating it allows me to prevent 
> that stall. That said, the number of channels should still be 
> kept within reason. Pretty much the entire point of ENet is 
> sending data within less latency than TCP by allowing you to 
> turn off stuff in TCP you normally couldn't.
> 
> Lee
> 
> Ruud van Gaal wrote:
> > 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
> >>     
> >
> > _______________________________________________
> > ENet-discuss mailing list
> > ENet-discuss at cubik.org
> > http://lists.cubik.org/mailman/listinfo/enet-discuss
> >
> >   
> 
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss