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