[ace-users] question on ACE_INET_Addr
shuston at riverace.com
Thu Aug 2 13:34:21 CDT 2007
Phil, your patch looks correct - as long as it works for Premkumar ;-)
I think, if I've understood this correctly, that the issue arose
because Premkumar built on a system containing all the IPv6 support
and ran on a different system that does not have IPv6 support. Or, at
least, one that has the support there but no IPv6 configured, so it's
essentially an IPv4 box.
Steve Huston, Riverace Corporation
Would you like ACE to run great on your platform?
> -----Original Message-----
> From: Phil Mesnier [mailto:mesnier_p at ociweb.com]
> Sent: Thursday, August 02, 2007 10:12 AM
> To: Premkumar P
> Cc: ace-users at cse.wustl.edu; shuston at riverace.com
> Subject: Re: [ace-users] question on ACE_INET_Addr
> 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
> > 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
> 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
> > 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,
> have an ACE library built with IPv6 support. This means that all the
> headers are available to define such things as AF_INET6,
> 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
> 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
More information about the Ace-users