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

[Michael Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/10/14 02:55, John Brooks wrote:
>> 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?

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.

>> 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.

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:
> 
> 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?

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUNQCRAAoJEBEET9GfxSfM49sIAKA8/m7PkC+GwgAe9zVYkcaP
540HFG73NFvtXK/z3Ww/prJsSwAJFSwXnKmYHLOp4upZ9E4+dtt82gOWorDxh9jR
ubv3nGIFZ4D+90LS5O28OHAGwz/9zdx7533xRI58pXMQQpuWcqsfk9KECKWolRcY
cEcLYXeUvnadbfR1HjEUp4RjXaw0KzXQwhXushs6bLTBUV29phhShDggHTYx/k4u
9FMHjLMn7neGnwvLyRUsaT9SCejB1HQJkpXGMwLKBB3B8VM8Gc1ZClISLz54qQQq
x5hWiV11NI5sTNVLuDYuA7xj2SIyTXtJGEj9y2N1STV1smVW1GOKkSW5hyzVoX4=
=LWzn
-----END PGP SIGNATURE-----