[ipv6] RFR: 8223532: Don't try creating IPv4 sockets in NetworkInterface.c if IPv4 is not supported

[Arthur Eubanks]

*From: *mark sheppard <macanaoire at hotmail.com>
*Date: *Thu, May 9, 2019 at 4:33 AM
*To: *Arthur Eubanks, Alan Bateman
*Cc: *OpenJDK Network Dev list

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.
>
I think that makes sense. There is a comment
// return partial list if an exception occurs in the middle of process ???
which hints toward doing that. But I think this can be a future change if
somebody thinks it's worth doing.

>
> 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.
>
I'm not sure that this is a big enough concern, but maybe others want to
comment on this.

>
> 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.
>
Good idea. With your comment I realized we don't need openSocket(), so I've
inlined it and made the socket creation exception more explicit as to
whether IPv4 or IPv6 socket creation failed.

>
> 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!!
>
Good catch. We still have the same problem with IPv6 version. Right now
ipv6_available() returns true if a stream socket, yet we still use it for
determining if we can create an IPv6 datagram socket.
I think it's good to converge the two as this change does. If anybody runs
in an environment where a stream socket can be created but not a datagram
socket (or vice versa), we may need more granularity for determining what
kinds of sockets are available.

>
> anyway main point -- should a failure to retrieve IPv4 interfaces preclude
> IPv6 interface retrieval and vice verse.
>
>
> regards
> Mark
>

New webrev:
 http://cr.openjdk.java.net/~aeubanks/8223532/webrev.02/index.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190509/145b9699/attachment.html>