[ENet-discuss] enet & techniques

Zola looseonthestreet at gmail.com
Sun Jul 30 18:20:28 PDT 2006


Hello, is anybody out there?
Lee?
Is this too tough of a subject?


On 7/25/06, celuyu celuyu <celuyu at gmail.com> wrote:
>
> Hello,
>
> 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.
> 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.
> 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."
> It can be found here:
> http://hci.usask.ca/publications/2006/game-networks.pdf
> 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.
> 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.
> The paper presents a number of features which it states are only existent
> in TNL and Raknet.
> 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.
>
> There's a good number of other differences in the libraries, but I'm
> concerned with Sections 4.1.3 through 5.1.
>
> In particular,
>
> Section 4.2.1, Combinations:
> For instance, Priority, and Deliver at all costs:
> The ability to have a "sequenced" policy: unreliable, but always in order.
> "The reliable sequenced policy drops all late arriving reliable
> information at the receiever."
>
> Section 4.2.2, TNL's message-level reliability:
> "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."
>
> Section 4.3.2, The current state data policy.
>
> Section 4.3.3, TNL's quickest delivery / QD policy:
> The abilty to trade bandwidth for lower latency, like Quake3's networking
> model. Can enet do this?
>
> And importantly, how it all comes together:
>
> Section 5.1, shows the possibily to choose the best combination of
> delivery methods for the given message:
> Reliable Unordered
> Reliable Ordered
> Unreliable Unordered
> Unreliable Ordered
> Unreliable Sequenced
> Each combined with a priority, or QD.
>
> 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.
>
> 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.
>
> Does enet just have "another way of doing it?"
> How can enet handle each of the combinations which were outlined?
> Further, what's the best way to handle aggregation with enet?
>
> - Celuyu
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cubik.org/pipermail/enet-discuss/attachments/20060730/8c7f1ee9/attachment.htm 


More information about the ENet-discuss mailing list