[ENet-discuss] ENet 2.0 most wanted features?

Soren Dreijer dreijer at echobit.net
Tue Apr 30 08:55:11 PDT 2013


Here are a few things I'd really like to see in 2.0:

 * Non-statically-sized internals, such as getting rid of the hardcoded
upper limit for the maximum number of peers (ENET_PROTOCOL_MAXIMUM_PEER_ID)

 * Configurable internals at runtime, such as setting the time in
milliseconds for ENET_PEER_TIMEOUT_MINIMUM and ENET_PEER_TIMEOUT_MAXIMUM
rather than leaving them hardcoded constants.

 * Better error handling; for instance, if a connection is disconnected,
it'd be really nice to know why, such as the underlying socket error, if it
isn't a graceful disconnect.

 * An improved message loop: ENet isn't thread-safe and expects all calls
to be made on the same thread, which means both sending and receiving have
to happen on the same thread. That's just fine, but unfortunately that
makes enet_host_service() a pain to work with. For instance, I don't want
to be a CPU hog and therefore won't be calling enet_host_service() in a
loop as fast as I can. Instead, I can pass a timeout value of, say, 1
to enet_host_service(), but this means I won't be able to send any packets
in that timeframe (which in reality is somewhere between 1-16 ms on
Windows). Now, it'd be absolutely great if there was a mechanism where I
could wait (read: block) for either a send or receive event and then handle
it as soon as one is available. That way, I'll be able to send and receive
packets as fast as possible without an arbitrary delay AND my application
won't be a CPU hog.

 * A nice C++ wrapper around ENet. It's a pain to work with C since I have
to explicitly make sure I RAII-ify everything to make sure things get
cleaned up properly.

Just my two cents.

/ Soren


On Tue, Apr 30, 2013 at 2:43 AM, Lee Salzman <lsalzman at gmail.com> wrote:

> So, I'm just thinking in the back of my mind what sort of things would be
> desired in a hypothetical version 2.0 of ENet that broke API compatibility
> and so could do things that would otherwise not be possible in a 1.x
> release.
>
> That doesn't mean that a 2.0 is in the near future, but I'd like to get a
> dialogue going about it.
>
> Aside from IPv6 support, are there any other big things people would want
> that are none-the-less realistic and not overly complicated?
>
> _______________________________________________
> 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/20130430/85924079/attachment.html>


More information about the ENet-discuss mailing list