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: [email protected] > [mailto:[email protected]] 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: [email protected] > >> [mailto:[email protected]] Namens Alex Milstead > >> Verzonden: Sunday, January 17, 2010 11:04 > >> Aan: [email protected] > >> 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 > >> [email protected] > >> http://lists.cubik.org/mailman/listinfo/enet-discuss > >> > > > > _______________________________________________ > > ENet-discuss mailing list > > [email protected] > > http://lists.cubik.org/mailman/listinfo/enet-discuss > > > > > > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
