-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 08/10/14 02:55, John Brooks wrote:
- 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?
Yup, that's right. So when the network is re-enabled we try building intro circuits straight away, in contrast to startup when we wait for the first circuit to be built.
I suggest submitting that separately from the control changes.
Thanks, I'll do that.
- 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.
Hmm, good point. The behaviour will be similar to SIGNAL NEWNYM but only affecting a single service. I'll look into the details.
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:
- 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?
I agree with your reading - this change is meant to avoid the first failed connection attempt in cases where we know it's likely to fail.
Another way to approach the problem would be to make the retention time of the HS descriptor cache configurable. Then clients connecting to mobile hidden services could set a shorter retention time than the default. But that would affect all hidden services used by the client. What I'm trying to achieve with this patch is a way of saying "I know this specific descriptor is likely to be out-of-date, don't bother trying it".
Cheers, Michael