[ENet-discuss] IPv6 Support
james at illusorystudios.com
Sun Jul 7 11:23:11 PDT 2013
On 7/7/2013 12:10 PM, John Cotton Ericson wrote:
> 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.
It doesn't have to break anything. Here's one possible route...
The ENetAddress in most ENet structures is effectively read-only. Add an
ENetAddress2 to ENetHost etc. and leave the others in as IPv4-only
mirrors of the real data.
Have it initialized with accessor functions, and give it a structure like
real data like port, address, type, etc;
There are reserved IPv4 addresses that can't exist on the net, and you
could use one of those for the magic. If the ENet address functions got
one of these, and enet_initialize_with_callbacks was passed a
sufficiently high version (so that the caller's structures have room for
the extra data), the structure could be assumed ENetAddress2. Otherwise,
it's an IPv4 address.
If one wanted to transparently add IPv6, the old struct ENetAddress
could become ENetCompatibleAddress, ENetHost's address could become
addressIPv4, a new ENetAddress 'address' could be added at the end. For
new projects compiling with new headers wanting compatibility with old
ENet versions, an "IPv4-only" define could be added.
Something like that. Your thoughts?
> 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.
Network byte order is an implementation detail of sockets. ENet's socket
code is an abstraction layer above that so folks don't have to be
exposed to it.
sockaddr_in and sockaddr_in6 are going to be inconsistent between
platforms. If you went this way, you would *have* to add accessor
functions even for port, or nobody can support cross-platform wrappers
that rely on the binary format (something that *mostly* has been
possible with ENet to date). I can't see a compelling reason to use the
platform-specific socket structs. Please do not do this.
More information about the ENet-discuss