One comment so far. The ipv4mode parameter in
getIPv4NetworkInterface()
seems superfluous, with the call using parameter value "0"
could be just elided to using the null return value directly.
I was a bit confused also that the new function is in the TwoStacks...
module,
but it seems this file contains native code common to both dual
stack/two stacks
mode. We probably should move this code to a different source file some
time,
but it might be useful to put a comment in at least to say that it is
common
to both modes.
Michael
On 15/09/13 12:34, Mark Sheppard wrote:
Hi
please oblige and review the webrev below which addresses the issue
problem:
https://bugs.openjdk.java.net/browse/JDK-6458027
webrev:
http://cr.openjdk.java.net/~msheppar/6458027/webrev/
the core of the issue is that a windows platform may be IPv6 enabled, but
an individual adapter/interface may not be configured with for IPv6.
This causes a problem with the MulticastSocket.setNetworkInterface()
and MulticastSocket.getNetworkInterface() methods.
The solution focuses on adding and additional check on the
individual interface for IPV6 enabling.
The fallback position when an adapter is not configured for IPV6, is to
handled it as IPV4, only.
It should be noted that setting an Interface which does not have a
valid IP address bound to it will result in a SocketException. As such, i
the onus in on the application to supply a validly configured
NetworkInterface object to the MulticastSocket.setNetworkInterface().
With this in mind, the set of Interfaces constructed for the
associated test
is based on the interface being up, multicast, and valid IP address
configured.
regards
Mark
