Hi Arthur et al. with these changes and the increased separation of IPv4 and IPv6 in the call flows, does it make sense to preclude the retrieval of IPv6 interfaces, if there is an error in the IPv4 processing in the enumInterfaces function ? Or that an error retrieving IPv6 interfaces precludes returning IPv4 interfaces already retrieved?
Is it worth considering the alternative to record the error and continue the attempt to retrieve IPv6 interfaces. If that succeeds clear the exception and return the IPv6 interfaces, and vice verse. An error in the IPv6 retrieval will preclude the return of the IPv4 interfaces already retrieved. A potential cause of failure in opening a socket is FD exhaustion at the moment of invocation (e.g. a constrained environment with open files 64 !!) which may have dissipated, if the call flow proceeds to retrieve the IPv6, while at the same time another thread has released an fd with file close or socket close. If not then it may be worth considering that any Exception thrown should elaborate the cause a bit more -- indicating the root cause is either IPv4 or IPv6 based, as per openSocketWithFallback. has the semantics of the openSocketWithFallback now changed ? was it not that an AF_INET6 socket creation was attempted if the AF_INET (IPv4) socket creation failed ? the predicate was on EPROTONOSUPPORT rather than EAFNOSUPPORT which is encaspulated in ipv4_available() Now it's if ipv4 not available then try ipv6. I know Chris made the point about treating them the same ... maybe so. But at a pedantic level, the function is creating datagram socke heret, while IPv4_supported created a stream socket!! anyway main point -- should a failure to retrieve IPv4 interfaces preclude IPv6 interface retrieval and vice verse. regards Mark ________________________________ From: net-dev <net-dev-boun...@openjdk.java.net> on behalf of Arthur Eubanks <aeuba...@google.com> Sent: Wednesday 8 May 2019 17:33 To: Alan Bateman Cc: OpenJDK Network Dev list Subject: Re: [ipv6] RFR: 8223532: Don't try creating IPv4 sockets in NetworkInterface.c if IPv4 is not supported Reverted changes in net_util.c. Also, webrev.00 would create an IPv6 socket even if creating the IPv4 socket was successful. Fixed. (My very first revision had this same issue, which I thought I had fixed before sending it out. Tricky if statements have been cleaned up to make this less likely to happen again in the future.) http://cr.openjdk.java.net/~aeubanks/8223532/webrev.01/ From: Alan Bateman <alan.bate...@oracle.com<mailto:alan.bate...@oracle.com>> Date: Wed, May 8, 2019 at 7:58 AM To: Chris Hegarty, Arthur Eubanks, OpenJDK Network Dev list On 08/05/2019 12:51, Chris Hegarty wrote: > > While the vast majority of libnet.so is devoted to socket related > implementation, not all is. There are a small number of low-level pieces > of functionality that can be used with support for either IPv4 or IPv6 > being present. The NIO implementation also uses some shared common > functionality from libnet.so. It seems overly restricting to disallow > libnet.so from loading if neither IPv4 or IPv6 are present. > I agree as an innocent reference to a type in java.net<http://java.net> might resulting in libnet being loaded as a side effect. We also have the issue that the file system implementation is in libnio so libnet will be loaded there too (although shouldn't trigger its JNI OnLoad to be run). -Alan