looking for some input on building client provider support for unix domain sockets
116 views
Skip to first unread message
Doug Tangren
Nov 9, 2014, 7:02:54 PM11/9/14
to asyncht...@googlegroups.com
I'm working building unix domain socket support for my docker client[1] which uses async http client under the hood for http client support. Docker does support http over tcp but it's not a default. I would like to build my interfaces to work out of the box. By default docker exposes its http api over a unix domain socket.
One of the fun challenges I've run into is java's lack of support for unix domain sockets. The short story is that java's socket interfaces are only defined with tcp in mind. These same socket interfaces are all that netty, the async http client provider I'm working with, understands. I picked a stable nio based third party unix socket library and created wrapper interfaces to get it to work with api's that only speak to java's socket interfaces. I got that working ( https://github.com/softprops/unisockets/blob/master/src/test/scala/SocketChannelSpec.scala ) but now I'm running into issues integrating this with async http client.
Aync http client provides a hook into netty's socket channel factory [2]. I've defined a custom client socket channel factory and plugged that into my async http provider properties. Where I'm getting stuck is the host field and how that translates the socket that a given request connects to. I traced this behavior back to the netty provider's `construct` method [3]. There' seems to be some scheme validation [4] that prevents me from using the unix:// scheme. Aside from that, it seems like I can override the default host resolution with the setVirtualHost method. Even with that I'm still having trouble seeing where the custom netty socket channel factory bridges my unix socket to the async http client request. I've got a few other ideas like extending the async netty provider and building the request myself but I want to make sure I'm taking full advantage of what's already available.
Can I get some advice on whether anyone here thinks I've been going down the wrong path or if these efforts seem futile? I'm starting to come to the conclusion that the cleanest path is a custom netty provider. URI's for these unix socket requests don't really have a host to resolve which I is why I thinking I'm having a hard time getting this to work with the current netty provider. Another acceptable answer is that http over unix domain sockets out out of the scope for async http client. I'm motivated to make this happen what ever the case is but I wanted to post my thoughts hear and get some expert feedback.
On a side note, in my travels through the jdk, netty and async http client interfaces, I've hit lots friction bumping up with final/package private classes and method definitions that prevented easy extension. I took a peak at what I'd need to do for the netty4-based async http client and noticed doing what I'm trying to do now will be _even harder_ as the netty provider class is final and doesn't provide a hook into translating the async http client request into a netty request. Please keep in mind how others may wish to extend your interfaces. final/package private interfaces have their place but are blockers for any kind of extension.
Stéphane Landelle
Nov 10, 2014, 4:36:12 AM11/10/14
to asyncht...@googlegroups.com
Hi Doug,
This thing is AsyncHttpClient is focused on it's own codebase, so it's difficult to anticipate how internal changes would impact third parties that would hack deep into it.
My 2 cents:
- another provider is a bad idea. It's already very complicated to have Netty and Grizzly providers aligned.
- the cleanest path would probably be to get in touch with the Netty guys and see with them how to bring unix domain support there, so AHC will be able to build on top of it. Did you do that?
Cheers,
Stéphane
--
You received this message because you are subscribed to the Google Groups "asynchttpclient" group.
To unsubscribe from this group and stop receiving emails from it, send an email to asynchttpclie...@googlegroups.com.
To post to this group, send email to asyncht...@googlegroups.com.
Visit this group at http://groups.google.com/group/asynchttpclient.
For more options, visit https://groups.google.com/d/optout.
Doug Tangren
Nov 10, 2014, 8:31:36 AM11/10/14
to asyncht...@googlegroups.com
On Mon, Nov 10, 2014 at 4:36 AM, Stéphane Landelle <slan...@excilys.com> wrote:
Hi Doug,This thing is AsyncHttpClient is focused on it's own codebase, so it's difficult to anticipate how internal changes would impact third parties that would hack deep into it.My 2 cents:
- another provider is a bad idea. It's already very complicated to have Netty and Grizzly providers aligned.
- the cleanest path would probably be to get in touch with the Netty guys and see with them how to bring unix domain support there, so AHC will be able to build on top of it. Did you do that?
I'll try that. I did have some luck last night by hooking into ahc's ProxyServer interface [1] which allows me to effectively set the InetAddress to connect to directly. It was a little bit of a hack but I tried exploiting that to then lift the Inet address into a unix socket address [2] and connect to that [3] in the socket channel my custom netty socket factory produces.
I'm working around some issues now with netty and some of its explicit typecasting but it looks like my path is now more clear with with ahc. The trick was setting the netty provider's socket channel factory property + exploiting a request's ProxyServer address.
Message has been deleted
kangtian pan
Oct 17, 2019, 7:42:51 AM10/17/19
to asynchttpclient
Hello, may I ask whether AsyncHttpClient support uds, or is ready to support
在 2014年11月10日星期一 UTC+8下午5:36:12，Stéphane Landelle写道：
在 2014年11月10日星期一 UTC+8下午5:36:12，Stéphane Landelle写道：
To unsubscribe from this group and stop receiving emails from it, send an email to asyncht...@googlegroups.com.
Stéphane LANDELLE
Oct 17, 2019, 8:30:15 AM10/17/19
to asyncht...@googlegroups.com
No it doesn't, and it's out of the scope of this library.
To unsubscribe from this group and stop receiving emails from it, send an email to asynchttpclie...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/asynchttpclient/64442b67-8e7d-4a44-bdaf-de28de3aee0e%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages