Dear Meejah, I'm replying by e-mail because it might be better than a conversation inside a github pull request.
Excellent idea about not launching tor all the time! We were just talking about that. My friend Leif Ryge and I were discussing possible designs for this tor hidden service endpoint... and what we realized is that the Tahoe-LAFS python process will have many endpoints it will listen on and many endpoints it will connect to. In this case we really want these features: - 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. - 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. 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. By the way... a bit about design patterns I'm using with twisted endpoints: In Foolscap and Tahoe-LAFS we cannot special case any usage of endpoint objects. Foolscap currently treats all endpoint objects in the exact same way... and in this sense is completely decoupled from the underlying wire protocol; Foolscap is totally decoupled from Tor. Tahoe-LAFS will have interesting Tor-friendly features like converting non-tor endpoint descriptor strings into tor endpoint descriptor strings... when running in "Tor-only" mode for instance. But Tahoe-LAFS in this case still should be totally decoupled from launching Tor AND decoupled from the twisted endpoints api; that is the job of Foolscap. However... Tahoe-LAFS only knows about endpoint descriptor strings... and this makes it's job very simple. Each component in the system has it's own simple responsibilities... this is why I wrote the parsers and why I cannot use extra additional public methods calling into an endpoint object. Sincerely, David _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
