<div dir="ltr">As a follow up I meant that it would allow us to simulate packet drops and packet sending speed. Also allowing to simulate a % for packet drop and packet sending through some parameter to the Host would be just as good if it's too complicated!<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 30, 2013 at 2:20 PM, Nuno Silva <span dir="ltr"><<a href="mailto:little.coding.fox@gmail.com" target="_blank">little.coding.fox@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">Also maybe some way to simulate different connection types so you could test your game without having to have those connections, this is mostly used in games but it would be very useful!<br>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Apr 30, 2013 at 2:10 PM, Doug Warren <span dir="ltr"><<a href="mailto:dwarren@thebigwave.net" target="_blank">dwarren@thebigwave.net</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">Shared Peer ids: Unique IDs shared among all peers connected in a mesh connection.  This would enable you to route a message to another peer if there is no direct connection due to firewall rules.<div><br>
</div>


<div>New packet type of best effort last message of a channel:  Any message for the channel would be unreliable but if we're sending a packet and the last acknowledged received sequence number is less than the last sent sequence number for that channel, a copy is sent anyway.  This could be used for frequently changing things like position but if there's room you'll get the most recent position anyway.</div>



<div><br></div><div>Packet out of ordering metrics: Can be added now easily enough, I always like thinking in terms of the console TCRs of requiring 64k throughput, 10% packet loss, 2% packet out of order.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>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>



</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><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></div></div><div>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">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></div></blockquote></div><br></div>
<br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">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></div></blockquote></div><br></div>