I've got Apache client 5.4.3 working with a custom connection operator that implements UDS support. I want to upstream this as a proper feature, since it's significantly more efficient than localhost. I want to discuss the design of this feature a bit; since it's a non-TCP transport layer, we have to be careful about how it's integrated into the overall design of the client.
CONVENTION There are a couple of ways clients expose UDS support. One is to use a URI scheme like unix or http+unix and provide the path to the socket as the URI authority: http+unix://%2Fpath%2Fto%2Fsocket/socket.sock/path?query This is a slight abuse of notation since Unix sockets are a transport, rather than an application-level concern; additionally, neither scheme has no IANA registration. Another solution is to provide the UDS path out-of-band, as in this example from curl's man page: curl --unix-socket socket-path https://example.com This is cleaner since it gives us a principled way to derive the Host header (typically localhost) and doesn't stuff transport details into the URI. It's also easier for end users to convert an existing localhost call to UDS. I think this is my preferred approach. The main question is which of the many config types should expose this option. RequestConfig seems reasonable, but there's also ConnectionConfig and SocketConfig. IMPLEMENTATION There are two options here: the JDK16 standard library, and JUnixSocket. I think we should do basically what we did for ALPN before JDK 1.8 Maintenance Release 3: model JUnixSocket as an optional dependency, use reflection to check for both implementations, and fail if neither one can be found. For JDK16 support we have the option of vending a multi-release jar, but this would add significant build-time complexity with little clear benefit over a MethodHandle set in a static initializer (this approach has equivalent performance to static linkage, for example). ASYNC According to my research, JDK16 and JUnixSocket both support non-blocking IO through the usual NIO abstractions like SocketChannel and Selector. SOCKET TYPES There are two types of Unix domain sockets. AF_UNIX is supported pretty much everywhere (even Windows) and is accessed as a file on the filesystem. Linux additionally offers abstract Unix domain sockets, which are accessed through a special namespace. Only AF_UNIX is supported by JDK16, so this feature would require JUnixSocket. I recommend only supporting AF_UNIX for the time being, since I'm not aware of any other HttpComponents features that are non-portable (such as epoll support). INTERACTIONS UDS support would need to work correctly with connection pooling, route modeling, and existing features like proxy support. Additionally, any code that assumes that the remote address is an InetAddress or InetSocketAddress may need to be adjusted. Finally, features like request logging and debug logging may need to account for the possibility of a UDS connection. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
