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
