On Oct 7, 2014, at 2:35 AM, Michael Rogers mich...@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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
- John
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
