[ENet-discuss] IPv6 Support

[James Bellinger]

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

struct ENetAddress2
{
uint8_t magicIPv6Marker[6];
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.

James