[tor-dev] Patches to improve mobile hidden service performance
john.brooks at dereferenced.net
Wed Oct 8 01:55:36 UTC 2014
On Oct 7, 2014, at 2:35 AM, Michael Rogers <michael at 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:
> 1. 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.
> 2. 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?
> 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).
> 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.
> tor-dev mailing list
> tor-dev at lists.torproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the tor-dev