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: [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
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
