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
