First of all, sorry I did not respond to your email earlier, James. I
think you responded before mailman finished processing my email address,
as I never received your response.
I had looked at Linux and Windows, and seen that they both used the same
sockaddr_in? structures (with network byte order for both the IP address
and socket). I assumed then that all sufficiently modern Unix variants
would also use it, but just in case cloned it's ABI for ENet, so in most
cases conversion would be a no-op, and users could rely on it being the
same even on esoteric systems were something different was native. (I
hadn't actually implemented the fall-back code though, just made
EnetAddress not depend on system types and instead "coincidently" mimic
them).
As to port-endianness, I too figured that in the vast majority of cases
EnetAddresses and port numbers would be passed around read-only so the
endianness of the port wouldn't be much of nuisance. For the rarer case
where somebody did need accesses functions could be provided. But yes,
as C has no way to really implement abstract data types, there is no way
to to ensure that users do indeed use the accessors, making this idea worse.
Of course, there is the other argument that it's best to have something
different from all platforms so no one gets in the habit of just casting
native sockaddrs to enetAddresses. I just checked, and found out that
Mac/BSD does uses something different, contrary to my expectations, and
Mac has enough market share that conversion would come up a lot on
practice too. Naturally, if a new structure is being used, it might as
well have port in native byte order.
So yes, I now whole-heartedly agree its best to disregard
system-specific types and just do something that's easiest for the ENet
user. However, I am not so sure about the "magic ipv4 address" idea.
First of all, anybody relying on the current size of EnetAddress will
still have compatibility broken. If they are relying on field offset, I
imagine they probably are doing likewise with structure size too, and
giving them a false notion of compatibility is more harmful than helpful.
Secondly, I feel like this is fundamentally holding backwards
compatibility above cleanliness of the interface. Having users grab
fields by offset is hardly friendlier than having them deal with
endianness themselves. It's also no more convenient than the casting and
offsetting that needs to be done with sockAddrs (though at at least ENet
will always be consistent across platforms).
If the point of this is making something that is both more consistent
/and nicer/ than the POSIX sockets interface, I think a tagged union is
the only way to go. Incidentally, The tag can be placed after the port,
which preserves the current offsets (though for the reasons above, I
don't think this is a good goal).
enum HostType {
IPv4 = 0;
IPv6 = -1;
}
struct EnetHostAddr6 {
enet_uint32 flowInfo;
enet_uint8 address[8];
enet_uint32 scopeID;
}
struct ENetAddress
{
enet_uint16 port;
enet_uint8 typeTag; // tag goeswhere padding did before
union {
enet_uint32 v4;
EnetIP6 v6;
} host;
};
-John
Where I looked for sockaddr_in6 info:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man4/inet6.4.html
http://linux.die.net/man/7/ipv6
http://msdn.microsoft.com/en-us/library/aa915715.aspx
On 07/13/2013 06:08 AM, Lee Salzman wrote:
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
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
