hi, <br>i dont have a idea about ACE_NAS_IPV6 but this is what i am doing,<br><br>i have build ACE 5.5.10 with ipv6 support by using ipv6 = 1 on Windows-XP machine using VC71<br><br>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.. <br>
<br>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.. <br><br>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.
<br>I came across a problem where from the debug message i could see that the notification pipe is failing to open, with error message &quot;Address family not supported&quot; ---- by looking at the code i found ACE_USES_IPV4_IPV6_MIGRATION and used it, which didn&#39;t solve the problem, so i added the change i had sent to !!!! which solves the instant problem
<br><br>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 job. <br><br>regards,<br>prem<br><br><br><br>ACE_USES_IPV4_IPV6_MIGRATION which solved most of the problems in spewhen using ACE_Proactor, SOCK_Acceptor, SOCK_Connector. 
<br><br><br><br><br><div><span class="gmail_quote">On 8/2/07, <b class="gmail_sendername">Phil Mesnier</b> &lt;<a href="mailto:mesnier_p@ociweb.com">mesnier_p@ociweb.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Premkumar P wrote:<br>&gt; hi,<br>&gt;<br>&gt; thankx for your help .. i will use the same in set function.<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I think a potential problem is that some functions, such as the set<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; function relied upon by the ctor modified below, are intended to let the
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; OS make the IPv4/IPv6 call if AF_UNSPEC is passed as the address family.<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; By using determine_type() to specify AF_INET or AF_INET6, we might end<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; up forcing something into an incorrect family. For example, we are
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; setting up an ACE_INET_Addr to contain the address of an external host<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; that really does not have IPv6, but with the local configuration,<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; determine_type() returns AF_INET6, then set() will fail because the
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; foreign address that should become IPv4 instead yields IPv6.<br>&gt;<br>&gt; cant really understand the problem you are talking about ! it would of<br>&gt; great help if can &#39;expand it a bit&#39;.<br>&gt;
<br><br>OK. ACE_INET_Addr has several set() methods, at least one of which takes<br>an optional address family parameter. The default value for this<br>parameter is AF_UNSPEC, meaning &quot;I don&#39;t care what address family you
<br>use.&quot; Passing either AF_INET or AF_INET6 means &quot;use this address family<br>or fail.&quot; Thus using determine_type() to select either AF_INET or<br>AF_INET6 may cause a failure where otherwise one might not happen.
<br>Consider that you are on a host with IPv6 support enabled, and you want<br>to create an ACE_INET_Addr (1234,&quot;foo.bar.baz&quot;) where foo.bar.baz is some<br>hostname. In your environment, foo.bar.baz resolves to only a single IPv4
<br>address. Using an address family of AF_UNSPEC, the set (unsigned short,<br>char[],...) method will initialize the address with an IPv4 address. If<br>the address family is pre-determined to be AF_INET6, then the set<br>
function will fail.<br><br>&gt; will there be any problem if i make this change in ACE_INET_Addr::set<br>&gt; function, if that is the case i have<br>&gt; to look for a different solution, as it is critical &quot;i don&#39;t break&quot; any
<br>&gt; functionality by making changes without understanding<br>&gt; the effect of it !!!!<br>&gt;<br><br>Do this. Revert your change to INET_Addr.cpp and try this:<br>Index: INET_Addr.cpp<br>===================================================================
<br>--- INET_Addr.cpp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (revision 79177)<br>+++ INET_Addr.cpp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (working copy)<br>@@ -331,6 +331,10 @@<br>&nbsp;&nbsp;&nbsp;&nbsp;struct addrinfo *res = 0;<br>&nbsp;&nbsp;&nbsp;&nbsp;int error = 0;<br>&nbsp;&nbsp;&nbsp;&nbsp;ACE_OS::memset (&amp;hints, 0, sizeof (hints));<br>
+# if defined (ACE_USES_IPV4_IPV6_MIGRATION)<br>+&nbsp;&nbsp;if (address_family == AF_UNSPEC &amp;&amp; !ACE::ipv6_enabled())<br>+&nbsp;&nbsp;&nbsp;&nbsp;address_family = AF_INET;<br>+# endif /* ACE_USES_IPV4_IPV6_MIGRATION */<br>&nbsp;&nbsp;&nbsp;&nbsp;if (address_family == AF_UNSPEC || address_family == AF_INET6)
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;hints.ai_family = AF_INET6;<br><br>Let me know how this works.<br><br>Now, can you answer a question for me? I am trying to figure out how your<br>error condition arose in the first place. From what I understand, you
<br>have an ACE library built with IPv6 support. This means that all the<br>headers are available to define such things as AF_INET6, sockaddr_in6,<br>etc. It also means that there is system library support for calls such as
<br>getaddrinfo() that can return IPv6 addresses. But when that address is<br>supplied to the acceptor (used by the reactor notify pipe) it is only<br>then that it is rejected?<br><br>That sounds like an even finer level of granularity than the current
<br>ACE_NAS_IPV6 allows. It sounds more like, there are IPv6 definitions, but<br>no runtime support. Ugh.<br><br>--<br>Phil Mesnier<br>Principal Software Engineer,&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://www.ociweb.com">http://www.ociweb.com</a>
<br>Object Computing, Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+01.314.579.0066<br><br></blockquote></div><br>