[ace-users] question on ACE_INET_Addr
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
> > OS make the IPv4/IPv6 call if AF_UNSPEC is passed as the address
> > By using determine_type() to specify AF_INET or AF_INET6, we might
> > up forcing something into an incorrect family. For example, we are
> > setting up an ACE_INET_Addr to contain the address of an external
> > 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...
More information about the Ace-users