What I was thinking a long time ago was to use a specific ipv4 host address as
the ipv6 marker, since the port is still necessary in any case. And then
underneath the port, reserve space for an actual ipv6 host address.
So you end up with something like:
struct ENetAddress
{
enet_uint32 host;
enet_uint16 port, reserved;
enet_uint32 flowInfo;
enet_uint8 address[16];
enet_uint32 scopeId;
};
Then have:
ENET_HOST_IPV6 = 0xAC1111AC
... where the above is some hex palindrome (reads same in both big and little
endian) is otherwise not a public ipv4 host.
So you set the host to ENET_HOST_IPV6 and just fill in the rest of the fields.
Most use cases of ENetAddress blah = { host, port }; would work as they always
did. Certain stuff could possibly even be mirrored between both ipv4 and ipv6
data when being passed back to the app.
Only real danger is that ENET_HOST_IPV6's value needs to be chosen well enough that it is
"unlikely" for it to ever occur in practice by accident or cause dangerous
behavior if it does.
On 07/07/2013 09:23 PM, James Bellinger wrote:
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
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
