UDS = Unix Domain Socket On Tue, Apr 22, 2025 at 2:07 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > Hi all, > > I'm not sure how to ask this question, so I'll be straightforward: If > UDS is https://en.wikipedia.org/wiki/Unified_Diagnostic_Services, why > should it be in an HTTP-focused project? > > I might have missed some context in a previous message of course. > > Gary > > On Mon, Apr 21, 2025 at 1:40 PM Ryan Schmitt <rschm...@apache.org> wrote: > > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
