I recently submitted a patch "sketching" IPv6 support for ENet:
https://github.com/lsalzman/enet/pull/21 . I say "sketching" as I
haven't tested it at all: once the issues below are resolved, I will
refine and test it, and then resubmit an actual patch.
The biggest issue with this patch is it breaks the current interface by
redesigning the EnetAddress structure. One can read the comments between
Lee Salzman and I on the github page, but I will summarize below:
I think we both agreed the interface change with IPv6 support is
inevitable. I thought simply incrementing the version number, and
supporting two versions for a time would be sufficient. He supported
changing the namespace (function prefix and header names I assume) in
order to avoid clashes.
I also questioned storing the port number in host byte order, when as
far as I know Windows and Unix consistently store it in network byte
order. I brought this up because in my implementation, I defined
EnetAddress as a union of the existing sockaddr_in and sockaddr_in6
structures, with the sole exception of keeping the portnumber in host
byte order as ENet currently does. Salzman responded that the ease of
working with port numbers in host byte order outweighed the extra
marshaling in the socket_* functions such a design decision entailed.
I was perfectly willing to follow his suggestions on both counts, but
Salzman suggested I ought to email the mailing list for this to be more
widely discussed. Looking at the mailing list archives (I just signed
up), I see there is plans for ENet 2. Perhaps making IPv6 support part
of that release would consolidate two rounds of interface changes into one?
- John
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
