new Tor connection handler: with_control_protocol_maker()

[Brian Warner]

To help with ​tahoe#2490, I think we need a connection-handler that accepts a "protocol maker" function. When called, this function returns a Deferred that fires with a txtorcon.TorControlProtocol object. The handler will then ask that object for the SOCKS port and make hint connectors using that port.

When Tahoe is configured to listen on an onion service, it needs to talk to Tor to allocate one. There's not much point (and a lot of inefficiency) to running multiple Tor daemons. So we'd like Tahoe and Foolscap to use the same one. The tahoe.cfg will have controls to specify how Tor should be reached (either control.port= or launch = true), which gives it the ability to spin up a (singleton) TorControlProtocol when necessary.

We can have Tahoe create a TorProvider object, with a get_control_protocol method (which returns a Deferred, which fires with a TorControlProtocol object). Internally this will use an Observer, and it will only create a single protocol object. Then the foolscap handler can ask it for the protocol object, and if it's the only one asking, a new one will be spun up. But if Tahoe has already spun one up (for onion-service listening purposes), it will get the existing one.

[dawuud]

ok here's my dev branches with these changes: ​https://github.com/david415/foolscap/tree/270.handle_tor_with_protocol_maker.0

( obviously it needs to be used with a patched tahoe as well ​https://github.com/david415/tahoe-lafs/tree/2490.tor_provider.0 )

it still needs it's tests to be fixed which would require mocking the TorProvider?.

[Brian Warner]

Thanks!

I was thinking about this more over the weekend though, I'd like to avoid making foolscap.connections.tor 's external API too dependent upon txtorcon (since passing around internal txtorcon objects will break if we ever switched to some other library). I was hoping there'd be a way to do that and also minimize the foolscap-side changes that need to be made.

So at the moment, I think the way to go is to add a tor.control_endpoint_maker. This would be given a callable (rather than an immediate Endpoint), which will be called at most once (and not until something needs Tor), and returns a Deferred, which fires with an Endpoint.

Then we change Tahoe to handle the launch = true case specially. Tahoe stops using foolscap.connections.tor.launch. We move most of the launch() code into Tahoe, into a new class which knows how to launch Tor, and can also provide the callable for control_endpoint_maker. This class launches Tor at most once, the first time either 1: tahoe.cfg wants an onion listener, 2: foolscap wants a tor connection handler.

[Brian Warner]

Ok, I've got a patch. I'm not yet 100% sure it's what we need for Tahoe (still working on that branch to see how it feels), but it's pretty small, which I like. I'm going to land it, but I'll hold off on making the next foolscap release until I've got a tahoe branch that looks approximately right, and if we need something completely different, I'll back it out and replace it with whatever was better.

[Brian Warner]

landed in [790ff9649]