[ace-users] question on ACE_INET_Addr
mesnier_p at ociweb.com
Thu Aug 2 09:11:43 CDT 2007
Premkumar P wrote:
> thankx for your help .. i will use the same in set function.
> I think a potential problem is that some functions, such as the set
> function relied upon by the ctor modified below, are intended to let the
> OS make the IPv4/IPv6 call if AF_UNSPEC is passed as the address family.
> By using determine_type() to specify AF_INET or AF_INET6, we might end
> up forcing something into an incorrect family. For example, we are
> setting up an ACE_INET_Addr to contain the address of an external host
> that really does not have IPv6, but with the local configuration,
> determine_type() returns AF_INET6, then set() will fail because the
> foreign address that should become IPv4 instead yields IPv6.
> cant really understand the problem you are talking about ! it would of
> great help if can 'expand it a bit'.
OK. ACE_INET_Addr has several set() methods, at least one of which takes
an optional address family parameter. The default value for this
parameter is AF_UNSPEC, meaning "I don't care what address family you
use." Passing either AF_INET or AF_INET6 means "use this address family
or fail." Thus using determine_type() to select either AF_INET or
AF_INET6 may cause a failure where otherwise one might not happen.
Consider that you are on a host with IPv6 support enabled, and you want
to create an ACE_INET_Addr (1234,"foo.bar.baz") where foo.bar.baz is some
hostname. In your environment, foo.bar.baz resolves to only a single IPv4
address. Using an address family of AF_UNSPEC, the set (unsigned short,
char,...) method will initialize the address with an IPv4 address. If
the address family is pre-determined to be AF_INET6, then the set
function will fail.
> will there be any problem if i make this change in ACE_INET_Addr::set
> function, if that is the case i have
> to look for a different solution, as it is critical "i don't break" any
> functionality by making changes without understanding
> the effect of it !!!!
Do this. Revert your change to INET_Addr.cpp and try this:
--- INET_Addr.cpp (revision 79177)
+++ INET_Addr.cpp (working copy)
@@ -331,6 +331,10 @@
struct addrinfo *res = 0;
int error = 0;
ACE_OS::memset (&hints, 0, sizeof (hints));
+# if defined (ACE_USES_IPV4_IPV6_MIGRATION)
+ if (address_family == AF_UNSPEC && !ACE::ipv6_enabled())
+ address_family = AF_INET;
+# endif /* ACE_USES_IPV4_IPV6_MIGRATION */
if (address_family == AF_UNSPEC || address_family == AF_INET6)
hints.ai_family = AF_INET6;
Let me know how this works.
Now, can you answer a question for me? I am trying to figure out how your
error condition arose in the first place. From what I understand, you
have an ACE library built with IPv6 support. This means that all the
headers are available to define such things as AF_INET6, sockaddr_in6,
etc. It also means that there is system library support for calls such as
getaddrinfo() that can return IPv6 addresses. But when that address is
supplied to the acceptor (used by the reactor notify pipe) it is only
then that it is rejected?
That sounds like an even finer level of granularity than the current
ACE_NAS_IPV6 allows. It sounds more like, there are IPv6 definitions, but
no runtime support. Ugh.
Principal Software Engineer, http://www.ociweb.com
Object Computing, Inc. +01.314.579.0066
More information about the Ace-users