-
Notifications
You must be signed in to change notification settings - Fork 350
sock5 proxy support #70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Sorry for the late response here!
|
Sorry, as soon as I hit post I realized ( |
i think we should also use rather for the interface we could do something like this (since
alternatively i also like the functional options pattern that would looke something like this:
and it could be used like this:
this does not entirely work for my usecase since in both cases one would have to pass the what do you think ? |
The former sounds right - and you're totally correct about |
Ok, this is going to be a bit painful. We need to thread the dialer down into:
|
With #77, there now exists a ClientOptions struct, so this should now be implementable. |
i need to interact with HDFS inside a private subnet in AWS over a secure jumphost and am currently doing that over a sock5 proxy.
i submitted #62 to be able to setup the namenode connection and pass it to the client.
this works for the cases where i only need to talk to the metadata server.
However, if i want to write to a file, the blockwriter opens a non proxy connection, which does not work for me:
here i need to setup the proxy again
I'd be happy to submit a patch but am not sure about what interface would be best here
the connection in both
rpc.NewNamenodeConnection
andrpc.BlockWriter.connectNext()
are both usingso this could be generalized to use a
or a
but that could not be set in
NewNamenodeConnection
anymore before making the connectionOr, in
NamenodeConnection
I could add this fieldand
rpc.BlockWriter
could use it if not nilor do you have a better suggestion?
The text was updated successfully, but these errors were encountered: