diff options
Diffstat (limited to 'src')
| -rw-r--r-- | src/or/bridges.c | 11 | ||||
| -rw-r--r-- | src/or/config.c | 9 | ||||
| -rw-r--r-- | src/or/directory.c | 4 |
3 files changed, 18 insertions, 6 deletions
diff --git a/src/or/bridges.c b/src/or/bridges.c index 0818fb0812..f2244004f3 100644 --- a/src/or/bridges.c +++ b/src/or/bridges.c @@ -632,7 +632,9 @@ fetch_bridge_descriptors(const or_options_t *options, time_t now) continue; } - /* schedule another fetch as if this one will fail, in case it does */ + /* schedule another fetch as if this one will fail, in case it does + * (we can't increment after a failure, because sometimes we use the + * bridge authority, and sometimes we use the bridge direct) */ download_status_failed(&bridge->fetch_status, 0); can_use_bridge_authority = !tor_digest_is_zero(bridge->identity) && @@ -787,8 +789,13 @@ learned_bridge_descriptor(routerinfo_t *ri, int from_cache) if (bridge) { /* if we actually want to use this one */ node_t *node; /* it's here; schedule its re-fetch for a long time from now. */ - if (!from_cache) + if (!from_cache) { download_status_reset(&bridge->fetch_status); + /* We have two quick attempts in the bridge schedule, and then slow + * ones */ + download_status_failed(&bridge->fetch_status, 0); + download_status_failed(&bridge->fetch_status, 0); + } node = node_get_mutable_by_id(ri->cache_info.identity_digest); tor_assert(node); diff --git a/src/or/config.c b/src/or/config.c index 30853724e4..54df6c3e58 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -586,7 +586,10 @@ static config_var_t option_vars_[] = { * blackholed. Clients will try 3 directories simultaneously. * (Relays never use simultaneous connections.) */ V(ClientBootstrapConsensusMaxInProgressTries, UINT, "3"), - V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "1200, 900, 900, 3600"), + /* The bridge code relies on the third item in this schedule being slow + * (~ 1 consensus interval) */ + V(TestingBridgeDownloadSchedule, CSV_INTERVAL, + "0, 8, 3600, 10800, 25200, 54000, 111600, 262800"), V(TestingClientMaxIntervalWithoutRequest, INTERVAL, "10 minutes"), V(TestingDirConnectionMaxStall, INTERVAL, "5 minutes"), V(TestingConsensusMaxDownloadTries, UINT, "8"), @@ -648,7 +651,9 @@ static const config_var_t testing_tor_network_defaults[] = { "15, 20, 30, 60"), V(TestingClientConsensusDownloadSchedule, CSV_INTERVAL, "0, 0, 5, 10, " "15, 20, 30, 60"), - V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "60, 30, 30, 60"), + /* The bridge code relies on the third item in this schedule being slow + * (~ 1 consensus interval) */ + V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "0, 5, 10, 30, 60"), V(TestingClientMaxIntervalWithoutRequest, INTERVAL, "5 seconds"), V(TestingDirConnectionMaxStall, INTERVAL, "30 seconds"), V(TestingConsensusMaxDownloadTries, UINT, "80"), diff --git a/src/or/directory.c b/src/or/directory.c index 57dfdd9cac..6b5e16bfd4 100644 --- a/src/or/directory.c +++ b/src/or/directory.c @@ -5663,8 +5663,8 @@ download_status_get_initial_delay_from_now(const download_status_t *dls) * (We find the zeroth element of the download schedule, and set * next_attempt_at to be the appropriate offset from 'now'. In most * cases this means setting it to 'now', so the item will be immediately - * downloadable; in the case of bridge descriptors, the zeroth element - * is an hour from now.) */ + * downloadable; when using authorities with fallbacks, there is a few seconds' + * delay.) */ void download_status_reset(download_status_t *dls) { |