[ENet-discuss] enet & techniques

[Lee Salzman]

There are some errata in that paper, most notably ENet has had 
aggregation since day 1. Reliability is message level in ENet too.
ENet has quite a few useful types of packets, encompassing reliable, 
unreliable, and unsequenced.

There is no equivalent to "quickest delivery" in ENet, although I did 
think this was a good idea when reading the paper. It just hasn't been 
terribly necessary in stuff I wrote ENet for, and ENet needs a major 
overhaul for various QoS things before I could really implement it.

ENet does "a lot", it just does not do "everything". The benefit of ENet 
is it is a small, efficient library that is unencumbered by stupid 
licensing - you can pretty much do whatever you want with it. If the 
other networking libraries weren't proprietary and/or did not have 
stupid licenses and were easier to plug in to games, I would have never 
written ENet.

I had a need, nothing filled it, and so I wrote ENet. I share it with 
others in the hope that it helps out others too, but realize I'm just 
one guy who wrote this as a hobby in his spare time, and as merely as 
part of a game I am working on. ENet does pretty much all the important 
stuff, but there are limits.

Although, I am going to be setting up a software/consulting LLC with my 
good friend Wouter van Oortsmersson soon, so if anyone wants to pay me 
to work on improvements to ENet without my distracting dayjob getting in 
the way for a while, be my guest. ;)

Lee

celuyu celuyu 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
>