[ace-users] question on ACE_INET_Addr

[Steve Huston]

Ok, great - thanks for the feedback on this, Andre!

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


> -----Original Message-----
> From: Andre Kostur [mailto:akostur at incognito.com] 
> Sent: Thursday, August 02, 2007 3:03 PM
> To: Steve Huston; Phil Mesnier; Premkumar P
> Cc: ace-users at cse.wustl.edu
> Subject: RE: [ace-users] question on ACE_INET_Addr
> 
> 
> 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
>