Updated webrev:
http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/
- added support for addresses enclosed in square brackets;
- updated SocketTransportService.java to handle empty hostname the same
way as JDWP agent (listen/attach to loopback address);
Has to update nsk/jdi/ListeningConnector/startListening/startlis001.java
(all other com/sun/jdi, nsk/jdi, nsk/jdwp, nsk/jdb test are passed).
--alex
On 04/01/2019 11:21, Alex Menkov wrote:
Hi Chris,
On 04/01/2019 04:50, Chris Hegarty wrote:
Alex,
On 29/03/2019 22:07, Alex Menkov wrote:
(added net-dev as suggested by Alan)
Net gurus, please assist in reviewing socket-related code.
New webrev:
http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/
Specifically on SocketTransportService.java. What Arthur has
proposed is better ( changing to lastIndexOf alone is not
sufficient ). Or is your assumption that the IPv6 literal is
not enclosed in square brackets?
I didn't know about enclosing IPv6 in square brackets, but looks like
that's standard way to alleviate conflict between IPv6 address and colon
as port separator.
Will update the fix to handle them in both JDI connectors
(SocketTransportService.java) and debugger agent (socketTransport.c)
If keeping Arthur's `static class HostPort` please make the
fields final.
>> Would it make sense to support the preference properties?
>> java.net.preferIPv4Stack
>> java.net.preferIPv6Addresses
I'm not sure about this, especially given the property name
prefixes. I need to think a little more on it.
In the initial version of the fix I didn't check the properties.
The rationale here is backward compatibility - is address is empty, old
debuggers tries to connect to IPv4 address only.
But handling this properties we will better handle clients with
properties set (as jdb or any other debugger which uses JDI connectors
are affected by the properties).
BTW fix provided by Arthur implements listening on localhost differently
- it creates several sockets and binds them to both IPv4 and IPv6
addresses. But the problem here (and that's the reason I decide to not
implement it this way) - how to handle the case when we successfully
bind on one address (for example IPv4), but fail to bind on other (for
example the port is busy for IPv6 stack). Arthur's version just fail in
the case (i.e. the whole Java process terminates) and I don't think this
is good behavior.
There is quite a bit of new native code, is it possible to
rewrite any of this in Java, e.g. reading of the system
properties ( if that is to remain )?
socketTransport.c is a debugger agent which is completely native.
--alex
-Chris.
