[ENet-discuss] A query about channels

Lee Salzman lsalzman1 at cox.net
Sun Jan 17 09:12:22 PST 2010


Unreliable packets are still sequenced, so can't be delivered until all 
preceding reliable packets are delivered.

Lee


Ruud van Gaal wrote:
> 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
>>     
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>   



More information about the ENet-discuss mailing list