On Oct 7, 2014, at 2:35 AM, Michael Rogers michael@briarproject.org wrote:
Hi all,
I've been experimenting with small changes to Tor to improve the performance of mobile hidden services. The following patches for Tor and jtorctl make two performance improvements:
- Each time the network's enabled, don't try to build introduction
circuits until we've successfully built a circuit. This avoids a problem where we'd try to build introduction circuits immediately, all the circuits would fail, and we'd wait for 5 minutes before trying again.
This sounds like a useful patch. Do you mean that status/circuit-established currently returns true after DisableNetwork is set?
I suggest submitting that separately from the control changes.
- Added a command to the control protocol to purge any cached state
relating to a specified hidden service. This command can be used before trying to connect to the service to force Tor to download a fresh descriptor. It's a more fine-grained alternative to SIGNAL NEWNYM, which purges all cached descriptors and also discards circuits.
You’ll need to update control-spec. I’m curious what would happen if you use this command on a HSDir or for a local service - those cases need to be defined.
I wonder what problem you’re trying to solve, and if this is the best solution. From a quick reading of the code tor’s behavior is:
1. If an intro point remains, try it 2. If we run out of intro points, re-fetch the descriptor 3. If we’ve tried fetching the descriptor from all HSDirs within the past 15 minutes, fail 4. If the descriptor is re-fetched, try all intro points again
The list of HSDirs used in the past 15 minutes seems to be cleared when a connection succeeds, when we give up connecting to a service, or on rendezvous failures.
Even if you hit that 15-minute-wait case, it looks like another connection attempt will re-fetch the descriptor and start over. See rendclient.c:1065, leading to purge_hid_serv_from_last_hid_serv_requests. Can you point out where your client gets stalled, or where I’ve read the logic wrong?
https://code.briarproject.org/akwizgran/briar/blob/9e5e2e2df24d84135f14adaa4...
https://code.briarproject.org/akwizgran/briar/blob/9e5e2e2df24d84135f14adaa4...
The Tor patch is based on the tor-0.2.24 tag, and the jtorctl patch is based on the Guardian Project's repo, which is ahead of the upstream repo (n8fr8 needs commit privileges for upstream, I think).
https://github.com/guardianproject/jtorctl
I've only done small-scale testing of these patches so far. If they seems like they might be useful I'll create a trac ticket to merge them.
Cheers, Michael
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
- John