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.
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. 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. On Tue, Apr 30, 2013 at 2:43 AM, Lee Salzman <[email protected]> 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 > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss > >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
