[ace-users] question on ACE_INET_Addr

Premkumar P kumaran.prem at gmail.com
Thu Aug 2 10:54:33 CDT 2007

i dont have a idea about ACE_NAS_IPV6 but this is what i am doing,

i have build ACE 5.5.10 with ipv6 support by using ipv6 = 1 on Windows-XP
machine using VC71

what i am trying to do is to make a build of ACE which will use IPV6 address
if it is available if not use IPV4. for this i need IPV6 support to be
enabled, but it was failed as it was always choosing IPV6 address even when
the machine didnt support that..

the machine i am currently working on is not configured for IPV6( it does
not have ipv6 address) .. so when i run the testcases it fails as it cant
get any IPV6 address..

using ACE::ipv6_enabled to check if ipv6 is available, and use AF_INET or
AF_INET6 as address_family for all address passed to SOCK_Acceptor /
SOCK_Connector solved some problem.
I came across a problem where from the debug message i could see that the
notification pipe is failing to open, with error message "Address family not
supported" ---- by looking at the code i found ACE_USES_IPV4_IPV6_MIGRATION
and used it, which didn't solve the problem, so i added the change i had
sent to !!!! which solves the instant problem

i will verify the same with the changes you have sent and let you know...
from what i know it should work good.. as both of them are doing the same


ACE_USES_IPV4_IPV6_MIGRATION which solved most of the problems in spewhen
using ACE_Proactor, SOCK_Acceptor, SOCK_Connector.

On 8/2/07, Phil Mesnier <mesnier_p at ociweb.com> wrote:
> Premkumar P wrote:
> > hi,
> >
> > 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:
> Index: INET_Addr.cpp
> ===================================================================
> --- 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.
> --
> Phil Mesnier
> Principal Software Engineer,    http://www.ociweb.com
> Object Computing, Inc.          +01.314.579.0066
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.isis.vanderbilt.edu/pipermail/ace-users/attachments/20070802/d6ab54d9/attachment.htm

More information about the Ace-users mailing list