Unix domain sockets (UDS, AF_UNIX) in System.inheritedChannel() and elsewhere in Java + [JDK-8231187] + [JDK-8231358]

[Michael McMahon]

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
>