[tor-dev] Patches to improve mobile hidden service performance

[John Brooks]

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? 

> 
> 
> https://code.briarproject.org/akwizgran/briar/blob/9e5e2e2df24d84135f14adaa42111c3ea2c55df8/tor.patch
> 
> https://code.briarproject.org/akwizgran/briar/blob/9e5e2e2df24d84135f14adaa42111c3ea2c55df8/jtorctl.patch
> 
> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

- John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20141007/89071fb7/attachment.sig>