[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