Skip to content
GitLab

Tor Connection: decrease "sign of life" timeout, increase bootstrap timeout

Merged intrigeri requested to merge 18501-tca-timeout into testing

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
  • 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
  • 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
Edited by intrigeri