enet
enet copied to clipboard
lsalzman
IPv6 support
I took some time to change the EnetAddress type to hold IPv6 and iPv4 addresses. I still need to test this, but I'd figure I'd submit a pull request anyways to see if you like my current methodology, and what I might change if you don't to eventually get IPv6 support upstream.
See enet.h for my revises documentation for EnetAddress, which basically shows my overall strategy for adding IPv6 support.
The problem with this is that it essentially has to live in a different directory/library namespace because it is a breaking API change. It'd have to be called something like enetv6 just to avoid breaking everything that includes enet/* or links against libenet.
Yeah, I couldn't see a way to do it without either braking the API, or making so many versions of each function that one might as well be including two versions of the library at once. The sockets interface itself added IPv6 without breaking the API, of course. But I think we both agree the way they support multiple address families is very clunky.
Perhaps you might massively increment the version number, keep it in a separate branch, and keep both around in an interim period to help people transition? With that plan, I doubt doing something like renaming the headers, or some other form of namespace change, is needed as this is not a subtle API change and it will cause plenty of compiling errors if it
Also, I noticed you stored the port number with native endianness, while as far as I know both Windows and Unix store it in network byte order. What was your rational for doing so? If you fully conform to the sockaddr_in and sockaddr_in6 APIs, good amount of the enet_socket_* wrappers can be simplified, maybe just to a few macro that interprets the different error-code conversions. This would also certainly help people writing bindings for ENet, as I am currently in Haskell, and I know others have done in at least Lua and Python. If IPv6 will break the current API anyways, perhaps this a good time to also make other interface-breaking changes like this.
The point was to actually make it easy to use. Having to do byte sex on the port all the time just to manipulate port numbers is annoying. Whereas addresses are kinda useless to manipulate directly unless in some other form and for that matter are usually just interpreted as byte strings anyway, unlike ports.
And a version number bump is not sufficient, sorry. It has to be a library rename or else there will be clashes that I don't want.
For reference, github comments are the entirely wrong place to have this discussion. I would appreciate it if you instead moved to the mailing list where other people can see it so it does not become one-sided.
Any update on this? :)
I'm a user of enet who thinks IPv6 support would be quite nice to have.
I'm swamped with life/work at the moment. I need a solid stretch of time in which to set up an enet2 branch and get things going, but not sure when that will be. Maybe over the winter holidays...
I am still around to work on this. As far as I know my email was the last in the thread in the mailing list.
We working on switch game http://freeminer.org/ to enet, and very need in ipv6 too.
Still way too busy to look into this right now. This summer will be the soonest I will have a big enough block of time for it.
https://github.com/freeminer/enet/tree/ipv6 - anything converted to AF_INET6 (v6+v4) without ipv4-only support. unix version working, win32 need to solve resolving
I was too busy with job commitments before to devote much time to ipv6 unfortunately, and it proved controversial enough that it wasn't a simple issue of someone else doing it and merging a pull request.
I can take a look into starting up an enet2 tree again over the next few weeks and figure out what I want to do with this. This would be a breaking change, though, since it seems impossible to satisfy everyone while maintaining backwards compatibility with the existing library's API and while supporting the same set of older platforms.
Thanks for the reply. From an API perspective, my thought was to do something like
- add
ENetAddress2, which has a family field (and reserves 128 bytes of space or so likestruct sockaddr_storage) - for every function that takes an
ENetAddress, add a version that takesENetAddress2, and stick 2 on the function name; turn the original into a wrapper - for structs containing
ENetAddressfields, add duplicateENetAddress2fields, and mirror to the original if the address is IPv4 - and/or maybe check for a magic define and, if set,
#define ENetAddress ENetAddress2and so on for all the functions and fields?
Not sure if this is worth it, but it would probably be nicer for distros than having to maintain two separate libraries.
What's the issue with older platforms?
Any news about this? We plan to migrate from raknet to enet but we depend on ipv6 support.
I've just been too busy to look into this lately. I have a lot of things going on...
On Sat, Jul 16, 2016 at 2:22 AM, Howard Chang [email protected] wrote:
Same here! Any news? It would be GREAT to have IPv6 support.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lsalzman/enet/pull/21#issuecomment-233113413, or mute the thread https://github.com/notifications/unsubscribe-auth/ABY60fgVC-QDOvnQeRbIJj66CiNJtgwbks5qWHjDgaJpZM4AyjQI .
