<div dir="ltr">Here are a few things I'd really like to see in 2.0:<br><div><br></div><div style> * Non-statically-sized internals, such as getting rid of the hardcoded upper limit for the maximum number of peers (ENET_PROTOCOL_MAXIMUM_PEER_ID)</div>
<div style><br></div><div style> * 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.</div>
<div style><br></div><div style> * 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.</div>
<div style><br></div><div style> * 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.</div>
<div style><br></div><div style> * 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. </div><div style><br>
</div><div style>Just my two cents.</div><div style><br></div><div style>/ Soren</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 30, 2013 at 2:43 AM, Lee Salzman <span dir="ltr"><<a href="mailto:lsalzman@gmail.com" target="_blank">lsalzman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>

<br></div><div>That doesn't mean that a 2.0 is in the near future, but I'd like to get a dialogue going about it.</div><div><br></div><div>Aside from IPv6 support, are there any other big things people would want that are none-the-less realistic and not overly complicated?</div>

</div>
<br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br></div></div>