[ENet-discuss] A query about channels

Alex Milstead alex.milstead at gatech.edu
Sun Jan 17 10:50:08 PST 2010


Thanks so much for all of the responses guys, this is great information!

So effectively the channeling system was put into place to help massage 
the load balance due to reliable and unreliable packets (if I've read 
this all correctly)? If this is the case, is the type of message being 
sent through to the "server" dictated by the last parameter for the 
"enet_packet_create" method? E.g., ENET_PACKET_TYPE_RELIABLE, is our 
reliable packet(s) (like a gun fire event or something), where as 
ENET_PACK_TYPE_UNSEQUENCED might be a chat packet, yes?

Also, Jay you mentioned earlier that it was easy to do simple data-type 
checking on the receiving end. I'm a bit of a fledgling network 
programmer -- I'm still definitely becoming more acquainted the vast 
amount of unfamiliar programming techniques in this particular arena. 
The only surefire type-checking system I know about in programming is in 
java (=/), with it's "instanceof" operator. As far as I know this type 
of mechanism, or anything similar, doesn't really exist in C/C++. So my 
next question is, if we're sending binary data along and receiving it as 
binary data, what's the most efficient way of type-checking the probable 
struct being piped through?

Cheers,
Alex

On 1/17/2010 12:12 PM, Lee Salzman wrote:
> 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
>>
>
> _______________________________________________
> 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