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