Re: Proxy support over AF_UNIX

[Dan Winship <danw gnome org>]

On 02/26/2013 05:42 AM, Ben Boeckel wrote:
> On Sat, Jan 26, 2013 at 15:14:54 -0500, Dan Winship wrote:
> > So, once all this stuff lands (soon),
>
> It appears as though the patch to use GProxyResolver for all proxy
> handling hasn't landed (the patch from the bug still applies). Will it
> land before 2.42.0 is released?

Yeah, I didn't want to commit it right before the last release, since it
could easily have broken things. And then I've been travelling for work
since then so I haven't gotten around to committing it yet...

> I'm looking at this again, trying to get a GProxy implementation
> working, but I seem to be lost in some black magic that GIO does with
> little to no documentation (that I can find). 

Yeah, it's not very well documented, and it's even worse for you because
your proxy is pretty fundamentally different from the SOCKS ones (which
just do a little bit of initial communication on the socket to set
things up, but then let the caller just use the original socket after
that). And I hadn't thought about all the details when I wrote my
earlier email, so I glossed over a lot of this...

> So far, I have a GProxy
> subclass which, based off of GSocks4aProxy, needs to do pretty much
> nothing in GProxy::connect other than return the given GIOStream.

No. The SOCKS proxies do that because, like I said above, all they need
to do is do some initial setup on the connection, but then the caller
uses the original connection normally.

In your case, you want to create an appropriate GUnixConnection in
::connect, and return that instead.

> However, I have no idea where I need to implement the socket/connect
> calls to create the GIOStream which gets passed to it (based on my
> reading of the docs which seems to state that the GProxy::connect
> GIOStream which is passed in is already connected to the proxy).

Yeah, so this is messy, because it's not a use case we'd thought about
when we wrote this originally. For SOCKS and HTTP proxies, when you
connect via a proxy, the first step is still to create a TCP connection;
you're just creating a TCP connection to the proxy server rather than to
the destination server. So GSocketClient will always start by creating a
TCP connection to the host and port identified in the proxy URI returned
by the GProxyResolver, and then it passes that GSocketConnection to
g_proxy_connect().

So you have to allow GSocketClient to make a TCP connection to
*somewhere*... one possibility would be for the GProxyResolver to return
a proxy URI containing the same host and port as the original request.
Then GSocketClient would connect to that host/port and pass the
GSocketConnection to your GProxy::connection, and then from there, you
could create your GUnixConnection, and then extract the file descriptor
from the original GSocketConnection and pass it over the unix socket...
although this gets tricky because the GSocketConnection is going to want
to close the socket when it's freed, so you'd have to dup() the fd or
something. Blah.

Maybe it would be easier to just use a TCP connection to localhost
rather than using a unix socket? So in that case, the proxy resolver
would return my-proxy-protocol://127.0.0.1:port/, and connect to your
proxy process that way, and then GProxy::connect would pass whatever
info the process on the other side needed, much like the SOCKS proxies do.

> For that matter, I have no idea how the GProxy subclass I've made gets
> into GProxyResolver. It appears as though it'll happen magically with
> g_io_extension_point_implement, but I also don't know where my GProxy
> subclass could say "yes, I implement that; use me".

Calling

    g_io_extension_point_implement (G_PROXY_EXTENSION_POINT_NAME,
                                    FOO_TYPE_PROXY,
                                    "foo",
                                    0);

tells glib that the GType FOO_TYPE_PROXY implements the "foo" proxy
scheme, so that if your GProxyResolver returns a "foo://..." URI,
GSocketClient will instantiate a FooProxy to connect to it.

-- Dan