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
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
