Hi Franta,
I have filed https://bugs.openjdk.java.net/browse/JDK-8231358
to cover the general case of support for UNIX domain sockets.
I think we should fix this bug independent of that though.
The test case you supplied incl. native launcher was useful for this.
So, thanks for that.
The change proposed here doesn't preclude any future
work in this area. I'll be updating my webrev shortly after
Alan's comments from Friday.
- Michael.
On 23/09/2019, 15:20, František Kučera wrote:
In response to: <https://bugs.openjdk.java.net/browse/JDK-8231187> and
<https://bugs.openjdk.java.net/browse/JDK-8231358>
> Best to ask František to argue his approach on nio-dev. The concern
with his approach is that it converts the local/remote address to an
IPv4 address, makes it looks like the socket is bound or connect to
the wildcard address.
Would be the 127.0.0.1 better? However I agree that this is not
optimal (this was intended as a hotfix changing minimum amount of code).
> More generally, ServerSocketChannel and SocketChannel aren't
appropriate channels to return because of the specified socket options
and half close semantics. It would require specification changes to
allow ServerSocketChannel and SocketChannel be channels for other
types of listener and stream-oriented channels.
I have successfully tested it with Jetty and Tomcat – they were able
to listen on an inherited unix domain socket (I can connect to them
e.g. using the socat command or Apache HTTPD configured as a reverse
proxy).
But again, I agree that using inet channels for other than inet
connections is bad. This was the reason why I suggested adding real
support for unix domain sockets:
<https://mail.openjdk.java.net/pipermail/net-dev/2019-July/012908.html>.
I wish unix domain sockets became first class citizens in Java (the
channel and address interfaces are generic enough and prepared for
such extension).
> This bug needs to be fixed independent of any future work to define
new channel types for Unix domain.
Agree, but please fix it in a backward compatible way.
> Would be useful to support a public API to AF_UNIX socket channels
for both connection sockets and listeners. Also, provide hook into
SelectorProvider.inheritedChannel.
Agree.
> Need to verify support in Windows, whether the new AF_UNIX sockets
can be multiplexed with existing networking sockets
Latest Windows versions have support for AF_UNIX, but they will
probably require different native C code than the network sockets
(while on unix systems the C code is almost the same).
Franta
