> >> IPv6 support is based on whether or not it finds the additional=20
> >> IPv6-specific API (getaddrinfo, e.g.).
> >
> >I don't know if this is such a good implementation -- or perhaps I should
> >say I don't think it is a complete solution.  Other platforms have the
> >ability to turn off IPv6 support independently of the API being available.=
> >=20
> >I've been thinking that the best way to determine whether IPv6 is available
> >is to check whether socket() returns (WSA)EPROTONOTSUPP.
> 
> Good point. Yes, I agree this is not an ideal way to detect if the platform 
> has "IPv6 support" available/enabled. The socket() test is a good idea.
> 
> In fact, I only used this to see if the IPv6 name resolution api 
> (getaddrinfo(), freeaddrinfo(),  and getnameinfo()) are available, so it's 
> not really IPv6 support per se that I want to check.
> 
> BTW, I would also like to add
> 
> hx_getaddrinfo()
> hx_getnameinfo()
> hx_freeaddrinfo()
> hx_gethostname()
> 
> to netdrv.cpp

This is probably a good idea if these are winsock API functions.

> How about I rename hx_netdrv_has_ipv6_support() to 
> hx_has_ipv6_resolver_api() or something like that.

Sounds good to me.

> Or, we could not offer hx_gethostname() or  hx_has_ipv6_resolver_api() and 
> just offer hx_getaddrinfo(), which would use call gethostname() if the 
> underlying getaddinfo() was not available, in which case we would allocate 
> ADDRINFO*. This is nicer but I'm not sure it is worth the additional work.
> 
> (Only the chxresolver implementation would/should be using these.)

I tend to agree that it's not worth the work, at least not right now.

> >What are the semantics when IPv6 is not available?  Should we allow the
> >caller to still use the Helix IPv6 API and translate the affected calls?=20
> >This would reduce quite a bit of complexity and code duplication in other
> >parts of the codebase.  Perhaps we could use a special socket family
> >HX_SOCK_FAMILY_IN_AUTO or somesuch to trigger this behavior.
> 
> I was assuming we would always allow the IPv6 API. It would just fail if 
> non-ipv4- mapped or ipv4 addresses are used. When an ipv4 compatible 
> address is passed in and ipv6 is not supported, we could extract the ipv4 
> address and pass through to the ipv4 api.

I was thinking this might cause problems, or at least unexpected behavior.
We should discuss this more.

> >What about Win2000?  The sockaddr_in6 decl in the IPv6 kit is the older
> >style that does not have a sin6_scope_id member.  Any functions that take a
> >sockaddr will fail at runtime because the sockaddr size is 4 bytes too
> >large.  This means that IPv6 requires either a special binary or some
> >workaround code at runtime to function on that platform.
> 
> I'm not sure, but the latest sdk docs do not say anything about special 
> handling of win2k. I suspect it should just work. An older win2k stack 
> should just ensure the size of sockaddr_in6 is at least as big as 
> expected.  A lot of win api take a struct size in addition to a struct 
> pointer and use the size as a proxy for a version.  You could probably use 
> the win2k older struct definition (or just subtract 4 from sizeof using the 
> current one) and pass it to the newer stack and it would probably succeed, 
> except in cases where the scope id is absolutely needed.

Now that I think of it, I was doing the reverse -- using the IPv6 kit
headers on WinXP.  That didn't work properly, of course, because the
sockaddr was 4 bytes too small.  Perhaps the IPv6 kit will work properly at
runtime.  The client team will probably want to verify this behavior (the
server won't be supporting Win2000).

> >> Client code that uses winsock should include this file as follows.
> >>=20
> >> #if defined(_WIN32)
> >> #if !defined(HELIX_CONFIG_STATIC_WINSOCK)
> >> #include "hxwinsocklib.h"
> >> #endif
> >> #endif
> >
> >Could that be put into hlxclib/sys/socket.h instead?  Seems to me that 
> >would
> >be a cleaner solution.
> 
> I originally planned to do that. The main reason I did not is because it 
> really only needs to be included in netdrv.cpp (and anywhere that might 
> conceivably use windows WSA functions, which in most cases we shouldn't 
> ever need). That combined with the fact that I #defined names like send, 
> recv, socket so that the netdrv code is identical regardless of whether or 
> not we are statically linking or going through the winsock wrapper. If we 
> put this in socket.h we then impose a header-ordering requirement (it can't 
> go before any headers that may have conflicting names, e.g, send).  An 
> alternative is not to #define the api names this way and change the way 
> they are called in netdrv.cpp - then including hxwinsocklib.h in socket.h 
> shouldn't ever result in weird problems depending on the header order.

Oh, okay.  I was under the impression that a lot of files would need to be
changed.  This sounds good if it's just for the network driver.

> >> --  moved following from nettypes.h to netdrv.{h,cpp}:
> >>=20
> >> u_long  hx_htonl(u_long hostlong);
> >> u_short hx_htons(u_short hostshort);
> >> u_long  hx_ntohl(u_long netlong);
> >> u_short hx_ntohs(u_short netshort);
> >
> >What motivated this?  And why did you switch to using functions in the .cpp
> >file instead of a #define (or at least a static inline)?  Ideally these
> >functions will reduce to a single instruction on most platforms, and I 
> >think
> >this will make it quite difficult for the compiler to do that.
> 
> I moved them because it seemed logical to group them with socket api rather 
> than type definitions.  Also, in windows some of these map to winsock api 
> calls and I wanted to have all the underlying calls into winsock be done in 
> one place in netdrv.cpp.
> 
> It's easy enough to re-add the #defines. (Are these really called in 
> performance sensitive code?)

By "some of these", do you mean inet_ntop() and inet_pton()?  Those changes
are fine.  I was just referring to the endian functions.

I don't know exactly where the endian functions are or will be called from,
but it seems that they should be reduced to inline instructions if at all
possible regardless of whether they are called from performance sensitive
code.  It's just nicer.  I originally put them in nettypes.h so they could
be used by all of the Helix code.

I suppose we should discuss this issue and standardize on a single set of
endian functions -- there are at least four different definitions in Helix
code that I know about.

-- 
The most difficult thing in the world is to know how to do a thing and to
watch someone else doing it wrong, without commenting.
        -- T.H. White
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.helixcommunity.org/pipermail/helix-client-dev/attachments/20040518/380812ab/attachment-0001.bin