[ace-users] question on ACE_INET_Addr

[Phil Mesnier]

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