Hello,<br><br>I've heard good things about enet; "enet's best.. Use enet, problem solved" -- from some good coders. I've been looking forward to using enet for my project.<br>I don't have a full understanding of low-latency networking concepts, and I figured that with enet, I'd discover how to do things best as I went.
<br>During my research to learn more on the subject, I came upon a little paper titled "Beyond the LAN: Techniques from Networked Games for Improving Groupware Performance."<br>It can be found here: <a href="http://hci.usask.ca/publications/2006/game-networks.pdf">
http://hci.usask.ca/publications/2006/game-networks.pdf</a><br>The paper was quite good for helping me to get a high level awareness of the techniques that are out there, and it compares a bunch of the libraries, including enet.
<br>It did, however, raise some questions about enet. I do not mean for this post to be about "who's best", but just to help me make a decision.<br>The paper presents a number of features which it states are only existent in TNL and Raknet.
<br>I realize that both are higher-level libraries, but this isn't an issue of interface- it's of the underlying methods used for transport and latency reduction.<br><br>There's a good number of other differences in the libraries, but I'm concerned with Sections
4.1.3 through 5.1.<br><br>In particular,<br><br>Section 4.2.1, Combinations:<br>For instance, Priority, and Deliver at all costs:<br>The ability to have a "sequenced" policy: unreliable, but always in order.<br>
"The reliable sequenced policy drops all late arriving reliable information at the receiever."<br><br>Section 4.2.2, TNL's message-level reliability:<br>"As an example, consider the same scenario as above where a packet is lost containing an unreliable movement message and a reliable ordered weapon fire message. The movement message could simply be dropped since delivery is not required, and the weapon fire message could be aggregated into the next packet to be sent, which eliminates the need to resend the lost packet."
<br><br>Section 4.3.2, The current state data policy.<br><br>Section 4.3.3, TNL's quickest delivery / QD policy:<br>The abilty to trade bandwidth for lower latency, like Quake3's networking model. Can enet do this?<br><br>
And importantly, how it all comes together:<br><br>Section 5.1, shows the possibily to choose the best combination of delivery methods for the given message:<br>Reliable Unordered<br>
Reliable Ordered<br>Unreliable Unordered<br>
Unreliable Ordered<br>
Unreliable Sequenced<br>Each combined with a priority, or QD.<br><br>As you can see in Section 5.1, a clear and logical diagram was drawn
up showing exactly which messages would require which kinds of
transmission. After reading this logical dissection of the combinations, it sounds great. This appeals to me, as I can envision immediately which kind of transmissions I'd use for each of my events. No single technique must make the whole stream inefficient, because you can choose what's best for each individual message.
<br><br>I noticed that enet doesn't do many of these things. I realize that this kind of feature analysis can often be one-dimensional, because it doesn't account for coding technique: how you use the library. I consider it's possible that enet doesn't do some of these things, because you go about solving the problem some-other-way.
<br><br>Does enet just have "another way of doing it?" <br>How can enet handle each of the combinations which were outlined?<br>Further, what's the best way to handle aggregation with enet?<br><br>- Celuyu<br>