Tor Connection: decrease "sign of life" timeout, increase bootstrap timeout
According to my initial tests (#18501 (comment 175745)) this should:
-
Make Tor Connection react 3 times faster when trying configurations that can't possibly work: wrong clock, blocked Tor, etc.
-
Allow bootstrapping even on much slower networks.
Closes #18501 (closed), #18539 (closed)
Test plan
Test all this with an enforced 24 KiB/s bandwidth cap:
-
No regression in automated tests, obviously. -
When Tor is blocked but default bridges are not, we fallback faster to default bridges. - 4.22~rc1:
- fallback to default bridges after 30s, then bootstrap times out after another 120s
- result: failure
- total: 150s
- this MR:
- fallback to default bridges after 10s, then succeeds after another 180s
- result: success
- total: 190s
- 4.22~rc1:
-
When using the default obfs4 bridges with a hardware clock set to Asia/Shanghai, we realize faster that we won't manage to connect, and allow the user to fix the clock - 4.22~rc1
- offers to fix the clock after 30s; then, after fixing the clock, it retries without bridges (#18462 (closed)) for 120s, times out, and finally retries with default bridges, which succeeds after 90s
- result: success
- time spent waiting for something that can't possibly work: 60s
- total with #18462 (closed) unfixed = 240s; total once #18462 (closed) is fixed: 120s
- this MR:
- offers to fix the clock after 10s; then, after fixing the clock, it retries without bridges (#18462 (closed)), which succeeds after 200s
- result: success
- time spent waiting for something that can't possibly work: 20s
- total with #18462 (closed) unfixed = 210s; total once #18462 (closed) is fixed: 100s
- 4.22~rc1
-
When Tor and default bridges are blocked, we realize faster that we won't manage to connect with out-of-the-box configuration, and offer the user to configure custom bridges. - 4.22~rc1:
- tries direct connection for 30s, then tries default bridges for 30s, then I enter my non-blocked bridge, and finally times out after 120s
- result: failure
- time spent waiting for something that can't possibly work: 60s
- total: 180s
- this MR:
- tries direct connection for 10s, then tries default bridges for 10s, then I enter my non-blocked bridge, which succeeds after 150s
- result: success
- time spent waiting for something that can't possibly work: 20s
- total: 170s
- 4.22~rc1:
Edited by intrigeri