-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Stainton <dstainton...@gmail.com> writes:
> I'm replying by e-mail because it might be better than a conversation
> inside a github pull request.
Good idea, thanks ;)
> - Each Twisted process (in this case Tahoe-LAFS) would use 1 (one)
> instance of Tor for all it's client and server communication. We don't
> want txsocksx to have to be dependent on txtorcon... however the
> txsocksx client tor endpoint could *optionally* read a txtorcon module
> variable specifying the tor socks port. If that fails then the tor
> client endpoint would try to find the system tor socks port.
I've been trying on and off to find a solution for similar
problems. Simplest is to answer "is there a Tor already running that's
suitable to connect to". In the general case, this seems "hard", and has
come up at least once on tor-dev -- the only really reliable thing I can
think of is "try to connect to every locally-listening port and speak
tor-control-protocol" which seems horrible...
For your use-case, it seems like there should be a good answer though :)
> - The first time a python process calls the `listen` method on a
> hidden service endpoint, the endpoint object will either use the
> system tor control port OR it will launch it's own tor process.
> (great... because we can reuse your new code for this...) Which ever
> it chooses it will then record this information in txtorcon module
> variables... so that if the same python process later creates more
> hidden service endpoints they will all use the tor process that was
> chosen by the first `listen` method call. This last part about
> tracking a single tor proc is not implemented yet... but Leif seemed
> close to finishing a patch for that. Once this is done then I will
> make the necessary changes to the txsocksx tor client endpoint.
Now I'm a little confused: doesn't the txsocksx client-endpoint do "TCP
over Tor" connections? That is, client-side connections? It shouldn't
really care about which Tor instance it's using (except, of course, that
you don't want to launch lots of them), right?
I guess maybe you mean you want "launch if 0 tors, re-use if 1" logic
here too?
> With this design we would not really need to specify the control port.
> We should probably still have it as an option.. however it isn't
> needed because if we try a few ports where the system control port
> might be and we cannot connect to it then in that case we should start
> tor with it's control port set to an unused port.
One thing I need to bear in mind a little as "the library author" is
that I know some people will want a "private tor no matter what" API
(which is of course still possible; just use txtorcon.launch_tor).
Perhaps providing a txtorcon API for "tell me all the tors you have
launched so far" would be a good thing. This would also be useful for
use-cases where you launch lots of tor instances (e.g. things like
Chutney, which launched a tor test network).
I think we've already rejected overloading controlPort= for two
different use-cases, right?
So how about somthing like this:
1. if controlPort is specified, and we can connect to it, great: we use
that Tor (if we can't connect, it's an error and things fail)
2. if controlPort is NOT specified, we do some "maybe auto launch"
logic:
a. if our list of launched tors isn't empty, we use the first one
b. if there's no launched tors yet, we launch one (and remember it)
I believe that will work for your usecase, even with the Tor bug where
we can't add to hidden-serivces in a running tor, because:
1. the first listen() takes a while because it launched a new tor, that
will be running as whatever user Foolscap/Tahoe-LAFS is running as
2. second and subsequent listen() calls will all use the tor from 1
which will have the right user (I might need to set "User=" until the
right tor bug is fixed)
3. note-to-self: make sure a second launch before the first has fully
suceeded correct waits for the first one ;) sounds like a unit-test :)
I'm still a little tempted to do something with overloading controlPort=
or adding another option so people get explicit control over whether a
new tor is launched or not ("launch=auto" which would be the default, as
above versus "launch=private" or "launch=never" maybe?)
[ Thanks for the explanation of your usecase :) ]
Also, thanks for your work on this!
I'm really glad we're getting this into txtorcon
Cheers,
- --
meejah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJTb6g+AAoJEJ0UOBRRgEVQ44oH/1v4/HmrXsNqUuGo+SzUs/W8
r/Qsvl2gKR+HmuIWaXIJY7NNvgb33Fe3dZO3y2K9pqTlyUok4fQMNgjl+fMFW70j
x4uexJAnskyuuhllk4x5IPEhFnDeLf01w4ELZ9fBW8IAwtZI6+pMI/xYM+S5djMP
CDcWuYt8U9nHAYtM7vQ8bqkcskKR9nynUSy+jIbx5PmyFpnyn9ZBB9CTu02DrUSJ
igSeNc0wPqzv9HlK5ga+VcGZS0So7YpHRquSSi27xF/jrmlnT3dciZOx9P8E3Afu
tlldafr1Wmgi39rvXVxvOAFLp30wGrl0yLu8cR+DAG0RPRaSTyHnS+AH/niFAUI=
=obko
-----END PGP SIGNATURE-----
_______________________________________________
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
