[ace-users] question on ACE_INET_Addr

[Andre Kostur]

I've worked with the IPv6 stuff in ACE, and using the
ACE_USES_IPV4_IPV6_MIGRATION (plus ipv6=1 in the features file) was
enough for my code to work on a v4-only host.  However, I haven't used
the Proactor yet.

-----Original Message-----
From: ace-users-bounces at cse.wustl.edu
[mailto:ace-users-bounces at cse.wustl.edu] On Behalf Of Steve Huston
Sent: Thursday, August 02, 2007 11:34 AM
To: 'Phil Mesnier'; 'Premkumar P'
Cc: ace-users at cse.wustl.edu
Subject: Re: [ace-users] question on ACE_INET_Addr

Hi folks,

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

--
Steve Huston, Riverace Corporation
Would you like ACE to run great on your platform?
See http://www.riverace.com/sponsor.htm


> -----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 
> 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
> 


_______________________________________________
ace-users mailing list
ace-users at mail.cse.wustl.edu
http://mail.cse.wustl.edu/mailman/listinfo/ace-users